MNG-3866: To fix or not to fix?

[Benjamin Bentmann]

Hi,

In the light of MNG-3866 [0], Shane and I had a short discussion what
should be the right behavior during model inheritance for handling
plugin definitions with different versions. Apparently, that is
something to discuss in the context of the community ;-), so please comment.

In Maven 2.x, <plugin> sections are merged based on the plugin key which
consists of groupId:artifactId, i.e. does not contain the plugin version
(c.f. ModelUtils.mergePluginLists()). This differs from Maven 3.x trunk
where <plugin> definitions are currently only merged if groupId,
artifactId and version match (c.f.
ArtifactModelContainer.containerAction()).

So, what's the proper behaviour?


Benjamin


[0] http://jira.codehaus.org/browse/MNG-3866

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Shane Isbell]

My primary concern is as follows. Say there is a version 1.1 of a plugin
specified in the pluginManagement section and that was joined with a plugin
of version 1.0. The plugin configuration information may be completely
incompatible. Also if you do the key off of version, you can define the same
plugin with different versions and different configs in the same
pluginManagement section.

Shane

On Sat, Nov 29, 2008 at 4:04 PM, Benjamin Bentmann <
benjamin.bentmann@...> wrote:

> Hi,
>
> In the light of MNG-3866 [0], Shane and I had a short discussion what
> should be the right behavior during model inheritance for handling plugin
> definitions with different versions. Apparently, that is something to
> discuss in the context of the community ;-), so please comment.
>
> In Maven 2.x, <plugin> sections are merged based on the plugin key which
> consists of groupId:artifactId, i.e. does not contain the plugin version
> (c.f. ModelUtils.mergePluginLists()). This differs from Maven 3.x trunk
> where <plugin> definitions are currently only merged if groupId, artifactId
> and version match (c.f. ArtifactModelContainer.containerAction()).
>
> So, what's the proper behaviour?
>
>
> Benjamin
>
>
> [0] http://jira.codehaus.org/browse/MNG-3866
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Jason van Zyl-5]

On 29-Nov-08, at 4:04 PM, Benjamin Bentmann wrote:

> Hi,
>
> In the light of MNG-3866 [0], Shane and I had a short discussion  
> what should be the right behavior during model inheritance for  
> handling plugin definitions with different versions. Apparently,  
> that is something to discuss in the context of the community ;-), so  
> please comment.
>
> In Maven 2.x, <plugin> sections are merged based on the plugin key  
> which consists of groupId:artifactId, i.e. does not contain the  
> plugin version (c.f. ModelUtils.mergePluginLists()). This differs  
> from Maven 3.x trunk where <plugin> definitions are currently only  
> merged if groupId, artifactId and version match (c.f.  
> ArtifactModelContainer.containerAction()).
>
> So, what's the proper behaviour?
>

The case where the version is taken into consideration is the proper  
way. As Shane already mentioned there is the case where configuration  
may be different, but for whatever reason you may need a plugin  
version that requires a different version of the plugin API. Something  
that will change in 3.x is the ability to isolate an execution  
environment given any set of artifacts. So in concrete terms it means  
that each version of the plugin API will have its own execution  
environment. In this way the old plugin API can be supported forever  
and a new API, with plugins based on that, can co-exist peacefully  
together indefinitely.

>
> Benjamin
>
>
> [0] http://jira.codehaus.org/browse/MNG-3866
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

  -- Thoreau


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[brettporter]

On 30/11/2008, at 11:04 AM, Benjamin Bentmann wrote:

> Hi,
>
> In the light of MNG-3866 [0], Shane and I had a short discussion  
> what should be the right behavior during model inheritance for  
> handling plugin definitions with different versions. Apparently,  
> that is something to discuss in the context of the community ;-), so  
> please comment.

Maybe I'm missing something but that issue seems to indicate a bug  
regardless since the configuration is completely lost instead of  
duplicated (assuming your latter example is complete).

On 30/11/2008, at 11:24 AM, Shane Isbell wrote:

> My primary concern is as follows. Say there is a version 1.1 of a  
> plugin
> specified in the pluginManagement section and that was joined with a  
> plugin
> of version 1.0. The plugin configuration information may be completely
> incompatible. Also if you do the key off of version, you can define  
> the same
> plugin with different versions and different configs in the same
> pluginManagement section.

Is there a use case for multiple versions of a plugin running on the  
same project? I'm concerned this adds some confusion in two ways:
* pluginManagement to dependencyManagement starts to behave  
differently - you won't actually be able to use it to apply a single  
version across a project
* it could become unclear when a plugin will be merged vs when it will  
be a second instance

I would see the first thing coming out being an enforcer rule to make  
sure you use a version consistently.

Some notes on the behaviour:

Is this something for a modelVersion increment? It seems this would  
break existing projects that are expecting them to merge, relying on  
the version mediation.

In the current version I think multiple definitions of a single plugin  
(whether the version matches or not), are ignored, so they will need  
to be changed to be honoured if they haven't already to be consistent  
with the new inheritance model.

Also the specific example that was given had no version at all - we  
discussed this at length before and it would seem in this case to make  
even more sense to require that the version be specified.

On 30/11/2008, at 11:47 AM, Jason van Zyl wrote:

>
> The case where the version is taken into consideration is the proper  
> way. As Shane already mentioned there is the case where  
> configuration may be different, but for whatever reason you may need  
> a plugin version that requires a different version of the plugin  
> API. Something that will change in 3.x is the ability to isolate an  
> execution environment given any set of artifacts. So in concrete  
> terms it means that each version of the plugin API will have its own  
> execution environment. In this way the old plugin API can be  
> supported forever and a new API, with plugins based on that, can co-
> exist peacefully together indefinitely.

When you say "will change", does it already work, or is this likely to  
cause problems in the interim?

- Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

Brett Porter wrote:

> Maybe I'm missing something but that issue seems to indicate a bug
> regardless since the configuration is completely lost instead of
> duplicated (assuming your latter example is complete).

Clarifying whether the behavior I observed with the plugin configuration
is a bug or a feature is the primary purpose of this thread.

For better illustration, I added another example to the JIRA issue that
a) uses explicit plugin versions in both parent and child
b) should be a little closer to real-life

Since people usually assume/expect plugin versions to be mostly
compatible, I personally feel Maven 2.x is making a better job at saving
me from XML clutter if I only want to use a different plugin version
than suggested by the parent.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[pbenedict]

I don't like the idea that I can use one version of the plugin as a
plugin (is there a better term for the use in a build?) and then
specify another version of the plugin for reporting. I find that it's
very difficult to keep them in sync since there are many plugins that
end up in both sections.

Paul

On Sun, Nov 30, 2008 at 4:46 AM, Benjamin Bentmann
<benjamin.bentmann@...> wrote:

> Brett Porter wrote:
>
>> Maybe I'm missing something but that issue seems to indicate a bug
>> regardless since the configuration is completely lost instead of duplicated
>> (assuming your latter example is complete).
>
> Clarifying whether the behavior I observed with the plugin configuration is
> a bug or a feature is the primary purpose of this thread.
>
> For better illustration, I added another example to the JIRA issue that
> a) uses explicit plugin versions in both parent and child
> b) should be a little closer to real-life
>
> Since people usually assume/expect plugin versions to be mostly compatible,
> I personally feel Maven 2.x is making a better job at saving me from XML
> clutter if I only want to use a different plugin version than suggested by
> the parent.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...