Plugin Versions in the Super pom

[Brian E Fox]

I know it's been discussed before in the context of various other issues
and solutions, but I want to discuss locking down core plugins in the
super pom _for_ 2.0 _only_.

 

Normally we get into some large protracted discussions about better
solutions and drawbacks/benefits of them, meanwhile the users suffer the
wrath of auto plugin updates. Considering the amount of time I spent
writing the enforcer requirePluginVersions rule, you can safely assume
you don't need to convince me that the _right_ way is to lock them down
in your poms. I already believe that. I also think that there is
probably a better solution, whether it's plugin packs (which I don't
agree with at this point) or something else. We can agree that whatever
else it is that may be done will come in 2.1 and for a large portion of
users 2.1 in production is a long way off and we continue to suffer "bad
press" about the instability of Maven in the mean time. So I'd like to
put those discussions aside for now and simply discuss the ramifications
of defaulting the core plugin versions in the super pom in 2.0 only.

 

I see two main benefits:

1.      Those who have followed best practice and locked their versions
down will not be affected by this at all. The normal inheritance rules
will apply, and we'll put these versions into the pluginManagement
section of the super pom.

2.      Those who have not locked their versions down will only be
affected by gaining stability in between maven releases. If they want a
new plugin before the next Maven release, they will have to follow the
best practices and lock their version down to the new version. (this
actually informs people and encourages them to learn how to do
that...but when _they_ are ready to do it because they are motivated to
grab a new release, not when they least expect it because we pushed out
a plugin that broke their build)

3.      The change is very simple, can be done quickly and has little
harm of creating more problems.

 

The only drawback I can see is that it lulls people into a false sense
of security because _less_ plugins auto update.... Not all of them.
Certainly we won't lock down every  plugin in existence and those
plugins will still be subjected to the auto update. Again, I'm not
suggesting we solve the world here, but this is a simple step forward to
reduce the impact of one of the most frequent complaints of the users.

 

If you can think of some serious drawbacks to this approach, speak now
for forever hold your peace ;-)

 

--Brian

 

 

[Carlos Sanchez-4]

I'm pretty much +1

Another behavior that would change is if I build and install a plugin
in my local repo, it won't be used. I'd have to explicitly set it in
the pom.

On Feb 8, 2008 4:41 PM, Brian E. Fox <brianf@...> wrote:

> I know it's been discussed before in the context of various other issues
> and solutions, but I want to discuss locking down core plugins in the
> super pom _for_ 2.0 _only_.
>
>
>
> Normally we get into some large protracted discussions about better
> solutions and drawbacks/benefits of them, meanwhile the users suffer the
> wrath of auto plugin updates. Considering the amount of time I spent
> writing the enforcer requirePluginVersions rule, you can safely assume
> you don't need to convince me that the _right_ way is to lock them down
> in your poms. I already believe that. I also think that there is
> probably a better solution, whether it's plugin packs (which I don't
> agree with at this point) or something else. We can agree that whatever
> else it is that may be done will come in 2.1 and for a large portion of
> users 2.1 in production is a long way off and we continue to suffer "bad
> press" about the instability of Maven in the mean time. So I'd like to
> put those discussions aside for now and simply discuss the ramifications
> of defaulting the core plugin versions in the super pom in 2.0 only.
>
>
>
> I see two main benefits:
>
> 1.      Those who have followed best practice and locked their versions
> down will not be affected by this at all. The normal inheritance rules
> will apply, and we'll put these versions into the pluginManagement
> section of the super pom.
>
> 2.      Those who have not locked their versions down will only be
> affected by gaining stability in between maven releases. If they want a
> new plugin before the next Maven release, they will have to follow the
> best practices and lock their version down to the new version. (this
> actually informs people and encourages them to learn how to do
> that...but when _they_ are ready to do it because they are motivated to
> grab a new release, not when they least expect it because we pushed out
> a plugin that broke their build)
>
> 3.      The change is very simple, can be done quickly and has little
> harm of creating more problems.
>
>
>
> The only drawback I can see is that it lulls people into a false sense
> of security because _less_ plugins auto update.... Not all of them.
> Certainly we won't lock down every  plugin in existence and those
> plugins will still be subjected to the auto update. Again, I'm not
> suggesting we solve the world here, but this is a simple step forward to
> reduce the impact of one of the most frequent complaints of the users.
>
>
>
> If you can think of some serious drawbacks to this approach, speak now
> for forever hold your peace ;-)
>
>
>
> --Brian
>
>
>
>
>
>

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

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

[Jason van Zyl-2]

On 8-Feb-08, at 4:52 PM, Carlos Sanchez wrote:

> I'm pretty much +1
>
> Another behavior that would change is if I build and install a plugin
> in my local repo, it won't be used. I'd have to explicitly set it in
> the pom.
>

Sure, but that's a minor inconvenience for us developing plugins in  
the default lifecycle, but for the user if it helps then it's a low-
tech solution that will help folks. I agree with Brian.

People are miseducated and that's our fault. The new version of the  
enforcer plugin helps, but if this helps stabilize things for those  
who haven't yet figured out that putting versions on your plugins is a  
good idea then so be it.

> On Feb 8, 2008 4:41 PM, Brian E. Fox <brianf@...> wrote:
>> I know it's been discussed before in the context of various other  
>> issues
>> and solutions, but I want to discuss locking down core plugins in the
>> super pom _for_ 2.0 _only_.
>>
>>
>>
>> Normally we get into some large protracted discussions about better
>> solutions and drawbacks/benefits of them, meanwhile the users  
>> suffer the
>> wrath of auto plugin updates. Considering the amount of time I spent
>> writing the enforcer requirePluginVersions rule, you can safely  
>> assume
>> you don't need to convince me that the _right_ way is to lock them  
>> down
>> in your poms. I already believe that. I also think that there is
>> probably a better solution, whether it's plugin packs (which I don't
>> agree with at this point) or something else. We can agree that  
>> whatever
>> else it is that may be done will come in 2.1 and for a large  
>> portion of
>> users 2.1 in production is a long way off and we continue to suffer  
>> "bad
>> press" about the instability of Maven in the mean time. So I'd like  
>> to
>> put those discussions aside for now and simply discuss the  
>> ramifications
>> of defaulting the core plugin versions in the super pom in 2.0 only.
>>
>>
>>
>> I see two main benefits:
>>
>> 1.      Those who have followed best practice and locked their  
>> versions
>> down will not be affected by this at all. The normal inheritance  
>> rules
>> will apply, and we'll put these versions into the pluginManagement
>> section of the super pom.
>>
>> 2.      Those who have not locked their versions down will only be
>> affected by gaining stability in between maven releases. If they  
>> want a
>> new plugin before the next Maven release, they will have to follow  
>> the
>> best practices and lock their version down to the new version. (this
>> actually informs people and encourages them to learn how to do
>> that...but when _they_ are ready to do it because they are  
>> motivated to
>> grab a new release, not when they least expect it because we pushed  
>> out
>> a plugin that broke their build)
>>
>> 3.      The change is very simple, can be done quickly and has little
>> harm of creating more problems.
>>
>>
>>
>> The only drawback I can see is that it lulls people into a false  
>> sense
>> of security because _less_ plugins auto update.... Not all of them.
>> Certainly we won't lock down every  plugin in existence and those
>> plugins will still be subjected to the auto update. Again, I'm not
>> suggesting we solve the world here, but this is a simple step  
>> forward to
>> reduce the impact of one of the most frequent complaints of the  
>> users.
>>
>>
>>
>> If you can think of some serious drawbacks to this approach, speak  
>> now
>> for forever hold your peace ;-)
>>
>>
>>
>> --Brian
>>
>>
>>
>>
>>
>>
>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

-- Jakob Burckhardt




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

[nicolas de loof-3]

+1

I've allready done similar "fix common plugins version" work in my corporate
POM, with version set for all
org.apache.maven.plugins and many org.codehaus.mojo.

Recent release of surefire plugin demonstrates many users suffering from the
"get latest" plugin policy, and some builds not beeing reproductible
anymore.

Nico.


2008/2/9, Brian E. Fox <brianf@...>:

>
> I know it's been discussed before in the context of various other issues
> and solutions, but I want to discuss locking down core plugins in the
> super pom _for_ 2.0 _only_.
>
>
>
> Normally we get into some large protracted discussions about better
> solutions and drawbacks/benefits of them, meanwhile the users suffer the
> wrath of auto plugin updates. Considering the amount of time I spent
> writing the enforcer requirePluginVersions rule, you can safely assume
> you don't need to convince me that the _right_ way is to lock them down
> in your poms. I already believe that. I also think that there is
> probably a better solution, whether it's plugin packs (which I don't
> agree with at this point) or something else. We can agree that whatever
> else it is that may be done will come in 2.1 and for a large portion of
> users 2.1 in production is a long way off and we continue to suffer "bad
> press" about the instability of Maven in the mean time. So I'd like to
> put those discussions aside for now and simply discuss the ramifications
> of defaulting the core plugin versions in the super pom in 2.0 only.
>
>
>
> I see two main benefits:
>
> 1.      Those who have followed best practice and locked their versions
> down will not be affected by this at all. The normal inheritance rules
> will apply, and we'll put these versions into the pluginManagement
> section of the super pom.
>
> 2.      Those who have not locked their versions down will only be
> affected by gaining stability in between maven releases. If they want a
> new plugin before the next Maven release, they will have to follow the
> best practices and lock their version down to the new version. (this
> actually informs people and encourages them to learn how to do
> that...but when _they_ are ready to do it because they are motivated to
> grab a new release, not when they least expect it because we pushed out
> a plugin that broke their build)
>
> 3.      The change is very simple, can be done quickly and has little
> harm of creating more problems.
>
>
>
> The only drawback I can see is that it lulls people into a false sense
> of security because _less_ plugins auto update.... Not all of them.
> Certainly we won't lock down every  plugin in existence and those
> plugins will still be subjected to the auto update. Again, I'm not
> suggesting we solve the world here, but this is a simple step forward to
> reduce the impact of one of the most frequent complaints of the users.
>
>
>
> If you can think of some serious drawbacks to this approach, speak now
> for forever hold your peace ;-)
>
>
>
> --Brian
>
>
>
>
>
>

[nicolas de loof-3]

I have to change my vote to -1 :

Current maven behavior introduces some issues when plugin version is not
set. Many users got errors with this and learned to use version.

Having maven super-POM set plugin version will make the build depend on
maven version used.

Simple scenario :

I create a project with maven 2.0.9, wich introduces superPOM
with versionned plugins. My build is reproductible even when new plugins are
released. This DOESN't learn me best-practices about plugins versionning.

Latter I come back to this project for maintenance with maven 2.0.11, that I
expect to be backward compatible. As not beeing a hacker I don't even know
what version of maven I'm using, simply run some eclipse integration (maybe
we will have some one day or the other)

... and the project gets broken as 2.0.11 superPOM doesn't set the same
plugins !


I got such scenario in REAL-WORLD projects using maven1 : maintenance
developers (maven newbees) had errors when building the project ... because
maven 1.1 was installed as default on the developer environment, and the
project used maven 1.0.2 with some uncompatible plugins.



I'd suggest another way to go :

Change maven to read the POM <prerequisites> and warn when installed maven
ISN't the one expected (could it accept version ranges ?). Or better : make
maven core automatically downgrade to expected runtime jars ?

Change the release plugin to require plugin version for all plugins (the one
configured + the one used by the packaging lifecycle).

Change maven to INFO when an unversionned plugin is used during build. Some
"best practice is to set plugin version ..." message would educate users.


As an alternative, the super POM could be published on central and not be
part of maven classpath, so that a project could set the version of this
superPOM to be used. Maven could BY DEFAULT use the one that matches running
maven version, and maybe log some "best-practice" info.

Nico.

2008/2/9, nicolas de loof <nicolas@...>:

>
> +1
>
> I've allready done similar "fix common plugins version" work in my
> corporate POM, with version set for all
> org.apache.maven.plugins and many org.codehaus.mojo.
>
> Recent release of surefire plugin demonstrates many users suffering from
> the "get latest" plugin policy, and some builds not beeing reproductible
> anymore.
>
> Nico.
>
>
> 2008/2/9, Brian E. Fox <brianf@...>:
> >
> > I know it's been discussed before in the context of various other issues
> > and solutions, but I want to discuss locking down core plugins in the
> > super pom _for_ 2.0 _only_.
> >
> >
> >
> > Normally we get into some large protracted discussions about better
> > solutions and drawbacks/benefits of them, meanwhile the users suffer the
> > wrath of auto plugin updates. Considering the amount of time I spent
> > writing the enforcer requirePluginVersions rule, you can safely assume
> > you don't need to convince me that the _right_ way is to lock them down
> > in your poms. I already believe that. I also think that there is
> > probably a better solution, whether it's plugin packs (which I don't
> > agree with at this point) or something else. We can agree that whatever
> > else it is that may be done will come in 2.1 and for a large portion of
> > users 2.1 in production is a long way off and we continue to suffer "bad
> > press" about the instability of Maven in the mean time. So I'd like to
> > put those discussions aside for now and simply discuss the ramifications
> > of defaulting the core plugin versions in the super pom in 2.0 only.
> >
> >
> >
> > I see two main benefits:
> >
> > 1.      Those who have followed best practice and locked their versions
> > down will not be affected by this at all. The normal inheritance rules
> > will apply, and we'll put these versions into the pluginManagement
> > section of the super pom.
> >
> > 2.      Those who have not locked their versions down will only be
> > affected by gaining stability in between maven releases. If they want a
> > new plugin before the next Maven release, they will have to follow the
> > best practices and lock their version down to the new version. (this
> > actually informs people and encourages them to learn how to do
> > that...but when _they_ are ready to do it because they are motivated to
> > grab a new release, not when they least expect it because we pushed out
> > a plugin that broke their build)
> >
> > 3.      The change is very simple, can be done quickly and has little
> > harm of creating more problems.
> >
> >
> >
> > The only drawback I can see is that it lulls people into a false sense
> > of security because _less_ plugins auto update.... Not all of them.
> > Certainly we won't lock down every  plugin in existence and those
> > plugins will still be subjected to the auto update. Again, I'm not
> > suggesting we solve the world here, but this is a simple step forward to
> > reduce the impact of one of the most frequent complaints of the users.
> >
> >
> >
> > If you can think of some serious drawbacks to this approach, speak now
> > for forever hold your peace ;-)
> >
> >
> >
> > --Brian
> >
> >
> >
> >
> >
> >
>

[Benjamin Bentmann]

> simply discuss the ramifications of defaulting the core plugin versions in
> the super pom in 2.0 only.

+1, might also spare users from learning yet another concept like
"plugin-packs". If the super POM locks down all plugins that would be
injected by one of the various lifecycle mappings and the user himself locks
down any additional plugins he explicitly configured in the POM, why bother
with something like "plugin-packs".

Besides, I do not see much value in an attempt to pack/group plugins given
the fact that each plugin has its own release cycle, i.e. there are more
version combinations of plugins from which I want to choose than you want to
provide plugin packs for.

Last but least and please don't take this as an offense but if you are
honest you have to confess that implementation of inheritance is
buggy/complex enough. As a user interested in a stable build tool, I really
dislike the idea of another concept that interferes with plugin resolution.

> Those who have followed best practice and locked their versions
> down will not be affected by this at all.

The reality looks different: http://jira.codehaus.org/browse/MNG-3394
As a prerequisite for the proposed additions to the super POM, this issue
should be fixed.

Regards,


Benjamin Bentmann


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

[jmcconnell]

+1 in principle.

One thought though....what if we were to add the activeProfile element as it
exists in the settings.xml into the pom.xml and advertise that users can set
something like this in their top level pom.xml:

<profiles>
  <activeProfiles>
    <activeProfile>default-maven-plugin-versioning</activeProfile>
  </activeProfiles>
</profiles>

This lets the behavior be optional, to be enabled as desired, is additive to
the pom.xml and accomplishes all of the same goals.

We advertise the hell out of it and people will discover it as they have a
problem that they resolve, can migrate to it as an upgrade process in their
company environments and we don't screw someone over with our benevolent
power.

thoughts?
jesse

On Feb 9, 2008 7:59 AM, Benjamin Bentmann <benjamin.bentmann@...> wrote:

> > simply discuss the ramifications of defaulting the core plugin versions
> in
> > the super pom in 2.0 only.
>
> +1, might also spare users from learning yet another concept like
> "plugin-packs". If the super POM locks down all plugins that would be
> injected by one of the various lifecycle mappings and the user himself
> locks
> down any additional plugins he explicitly configured in the POM, why
> bother
> with something like "plugin-packs".
>
> Besides, I do not see much value in an attempt to pack/group plugins given
> the fact that each plugin has its own release cycle, i.e. there are more
> version combinations of plugins from which I want to choose than you want
> to
> provide plugin packs for.
>
> Last but least and please don't take this as an offense but if you are
> honest you have to confess that implementation of inheritance is
> buggy/complex enough. As a user interested in a stable build tool, I
> really
> dislike the idea of another concept that interferes with plugin
> resolution.
>
> > Those who have followed best practice and locked their versions
> > down will not be affected by this at all.
>
> The reality looks different: http://jira.codehaus.org/browse/MNG-3394
> As a prerequisite for the proposed additions to the super POM, this issue
> should be fixed.
>
> Regards,
>
>
> Benjamin Bentmann
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
jesse mcconnell
jesse.mcconnell@...

[Brian E Fox]

<snip comments about plugin packs that I happen to agree with>

>The reality looks different: http://jira.codehaus.org/browse/MNG-3394
>As a prerequisite for the proposed additions to the super POM, this
issue
>should be fixed.


Yes. I moved it to 2.0.9 as this definitely is related.

--Brian


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

[Brian E Fox]

>We advertise the hell out of it and people will discover it as they have a
>problem that they resolve, can migrate to it as an upgrade process in their
>company environments and we don't screw someone over with our benevolent
>power.

I think the biggest beef people have is that we are unstable by default. I don't think that requiring some action to get the versions locked is really going to help much. Otherwise we just continue to advertise the hell out of locking down your versions in the pom (which hasn't been working).

--Brian

[Brian E Fox]

>I have to change my vote to -1 :

>Current maven behavior introduces some issues when plugin version is
not
>set. Many users got errors with this and learned to use version.

>Having maven super-POM set plugin version will make the build depend on
>maven version used.

Compare this change to the current behavior. People simply are not
locking them down either because they don't know or they don't want to
make huge xmls. (remember I still think locking them down is the right
way to do it, but apparently the majority of the users don't/won't). So
if we do nothing, they are just as likely to have un-reproducible builds
with a later version of maven. And worse, they potentially break across
developers because their machines have different versions and it changes
suddenly without them having any interaction.

What you point out is definitely a risk, but I see it as less harmful
than the current method.

--Brian


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

[Aaron Metzger]

Brian E. Fox wrote:

>> We advertise the hell out of it and people will discover it as they have a
>> problem that they resolve, can migrate to it as an upgrade process in their
>> company environments and we don't screw someone over with our benevolent
>> power.
>
> I think the biggest beef people have is that we are unstable by default. I don't think that requiring some action to get the versions locked is really going to help much. Otherwise we just continue to advertise the hell out of locking down your versions in the pom (which hasn't been working).
>
> --Brian
>
>

A tiny inexperienced voice from the user side of things chiming in here...

For me, I am completely aware that I want to lock *everything* down
(including plugins) to have reproducible builds.  So marketing,
advertising, pleading with us, educating us is not the issue.

The problem is not knowing or being able to keep up with the list of
what combination of plugins and maven versions work well together.

Whether or not the list of plugin versions is in the super POM is not
the isue for me. It is the wisdom and experience of the person who would
make the choices of which versions of the plugins to put in that default
list that is the real value.

In general I don't want to have to make those choices for every plugin
-- just the occasional exception for when I really need some new feature
or old compatibility.

Either of two approaches would satisfy me:

1)  Benevolent dictators strongly suggest the list of plugin versions
which are thought to be stable together and that is in the super POM or
I just cut-n-paste the suggested list in there myself from the web site.

2)  I just go ahead and try my build process using all the latest plugin
versions (current default behavior) and then when I see that they all
work together have some mechanism to freeze the list and have the
current versions (whatever they are) automatically written into my POM
without me having to sort through and figure out what the versions are
and manually insert them into the POM.  I would want to be able to
freeze the list not just at release time but at any arbitrary time to
stabilize the development environment for my team.


Thanks.





--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

[Jason van Zyl-2]

On 9-Feb-08, at 5:53 AM, nicolas de loof wrote:

> I have to change my vote to -1 :
>
> Current maven behavior introduces some issues when plugin version is  
> not
> set. Many users got errors with this and learned to use version.
>
> Having maven super-POM set plugin version will make the build depend  
> on
> maven version used.
>
> Simple scenario :
>
> I create a project with maven 2.0.9, wich introduces superPOM
> with versionned plugins. My build is reproductible even when new  
> plugins are
> released. This DOESN't learn me best-practices about plugins  
> versionning.
>

We all fully realize that. The change is to help the unsuspecting, and  
the general user who is not going to read anything and just expects  
not to be surprised. This helps the general situation irrespective of  
people learning best practices. It provides a higher degree of  
stability people should be setting versions. It's the nature of users.

> Latter I come back to this project for maintenance with maven  
> 2.0.11, that I
> expect to be backward compatible. As not beeing a hacker I don't  
> even know
> what version of maven I'm using, simply run some eclipse integration  
> (maybe
> we will have some one day or the other)
>

Yes, but in the meantime they have had stability. If they had plugins  
that weren't versioned they could have been broken any number of  
places from the switch to different versions of Maven.

> ... and the project gets broken as 2.0.11 superPOM doesn't set the  
> same
> plugins !

Overall the stability is still increased.

>
>
>
> I got such scenario in REAL-WORLD projects using maven1 : maintenance
> developers (maven newbees) had errors when building the project ...  
> because
> maven 1.1 was installed as default on the developer environment, and  
> the
> project used maven 1.0.2 with some uncompatible plugins.
>
>
>
> I'd suggest another way to go :
>
> Change maven to read the POM <prerequisites> and warn when installed  
> maven
> ISN't the one expected (could it accept version ranges ?). Or  
> better : make
> maven core automatically downgrade to expected runtime jars ?
>

Too complicated.

Using the enforcer plugin setting the Maven version would prevent a  
problem from happening. Prerequisites are not for setting the user's  
version of Maven, it's for setting the requirement of the plugin.

> Change the release plugin to require plugin version for all plugins  
> (the one
> configured + the one used by the packaging lifecycle).
>

Too complicated, and people might not use the release plugin.

> Change maven to INFO when an unversionned plugin is used during  
> build. Some
> "best practice is to set plugin version ..." message would educate  
> users.
>

The enforcer plugin with the right rules can already do this (when  
it's released, ahem, Brian :-))

>
> As an alternative, the super POM could be published on central and  
> not be
> part of maven classpath, so that a project could set the version of  
> this
> superPOM to be used. Maven could BY DEFAULT use the one that matches  
> running
> maven version, and maybe log some "best-practice" info.
>

Too complicated.

You're asking for a far more complicated solutions to be implemented  
which generally aren't much more helpful. You're also conflating the  
solution with what people should do and what they should actually be  
doing. Yes, people should use versions for their plugins, but in the  
absence of that putting the versions in the POM is the easiest  
solution to provide the most stability, in most cases.

> Nico.
>
> 2008/2/9, nicolas de loof <nicolas@...>:
>>
>> +1
>>
>> I've allready done similar "fix common plugins version" work in my
>> corporate POM, with version set for all
>> org.apache.maven.plugins and many org.codehaus.mojo.
>>
>> Recent release of surefire plugin demonstrates many users suffering  
>> from
>> the "get latest" plugin policy, and some builds not beeing  
>> reproductible
>> anymore.
>>
>> Nico.
>>
>>
>> 2008/2/9, Brian E. Fox <brianf@...>:
>>>
>>> I know it's been discussed before in the context of various other  
>>> issues
>>> and solutions, but I want to discuss locking down core plugins in  
>>> the
>>> super pom _for_ 2.0 _only_.
>>>
>>>
>>>
>>> Normally we get into some large protracted discussions about better
>>> solutions and drawbacks/benefits of them, meanwhile the users  
>>> suffer the
>>> wrath of auto plugin updates. Considering the amount of time I spent
>>> writing the enforcer requirePluginVersions rule, you can safely  
>>> assume
>>> you don't need to convince me that the _right_ way is to lock them  
>>> down
>>> in your poms. I already believe that. I also think that there is
>>> probably a better solution, whether it's plugin packs (which I don't
>>> agree with at this point) or something else. We can agree that  
>>> whatever
>>> else it is that may be done will come in 2.1 and for a large  
>>> portion of
>>> users 2.1 in production is a long way off and we continue to  
>>> suffer "bad
>>> press" about the instability of Maven in the mean time. So I'd  
>>> like to
>>> put those discussions aside for now and simply discuss the  
>>> ramifications
>>> of defaulting the core plugin versions in the super pom in 2.0 only.
>>>
>>>
>>>
>>> I see two main benefits:
>>>
>>> 1.      Those who have followed best practice and locked their  
>>> versions
>>> down will not be affected by this at all. The normal inheritance  
>>> rules
>>> will apply, and we'll put these versions into the pluginManagement
>>> section of the super pom.
>>>
>>> 2.      Those who have not locked their versions down will only be
>>> affected by gaining stability in between maven releases. If they  
>>> want a
>>> new plugin before the next Maven release, they will have to follow  
>>> the
>>> best practices and lock their version down to the new version. (this
>>> actually informs people and encourages them to learn how to do
>>> that...but when _they_ are ready to do it because they are  
>>> motivated to
>>> grab a new release, not when they least expect it because we  
>>> pushed out
>>> a plugin that broke their build)
>>>
>>> 3.      The change is very simple, can be done quickly and has  
>>> little
>>> harm of creating more problems.
>>>
>>>
>>>
>>> The only drawback I can see is that it lulls people into a false  
>>> sense
>>> of security because _less_ plugins auto update.... Not all of them.
>>> Certainly we won't lock down every  plugin in existence and those
>>> plugins will still be subjected to the auto update. Again, I'm not
>>> suggesting we solve the world here, but this is a simple step  
>>> forward to
>>> reduce the impact of one of the most frequent complaints of the  
>>> users.
>>>
>>>
>>>
>>> If you can think of some serious drawbacks to this approach, speak  
>>> now
>>> for forever hold your peace ;-)
>>>
>>>
>>>
>>> --Brian
>>>
>>>
>>>
>>>
>>>
>>>
>>

Thanks,

Jason

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

Three people can keep a secret provided two of them are dead.

-- Unknown




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

[Jason van Zyl-2]

On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote:

> Brian E. Fox wrote:
>>> We advertise the hell out of it and people will discover it as  
>>> they have a
>>> problem that they resolve, can migrate to it as an upgrade process  
>>> in their
>>> company environments and we don't screw someone over with our  
>>> benevolent
>>> power.
>> I think the biggest beef people have is that we are unstable by  
>> default. I don't think that requiring some action to get the  
>> versions locked is really going to help much. Otherwise we just  
>> continue to advertise the hell out of locking down your versions in  
>> the pom (which hasn't been working).
>> --Brian
>
> A tiny inexperienced voice from the user side of things chiming in  
> here...
>
> For me, I am completely aware that I want to lock *everything* down  
> (including plugins) to have reproducible builds.  So marketing,  
> advertising, pleading with us, educating us is not the issue.
>
> The problem is not knowing or being able to keep up with the list of  
> what combination of plugins and maven versions work well together.
>
> Whether or not the list of plugin versions is in the super POM is  
> not the isue for me. It is the wisdom and experience of the person  
> who would make the choices of which versions of the plugins to put  
> in that default list that is the real value.
>
> In general I don't want to have to make those choices for every  
> plugin -- just the occasional exception for when I really need some  
> new feature or old compatibility.
>
> Either of two approaches would satisfy me:
>
> 1)  Benevolent dictators strongly suggest the list of plugin  
> versions which are thought to be stable together and that is in the  
> super POM or I just cut-n-paste the suggested list in there myself  
> from the web site.
>

The code in the enforcer plugin can actually extract the versions that  
were used as part of a build so we could turn this into something  
people could use. John has also been working on a lifecycle plugin  
which displays the information about the lifecycle which means we  
could extract the information from that too and make a descriptor. So  
we can test different combinations of plugins as they are released and  
give those combinations to users in some controlled way.

> 2)  I just go ahead and try my build process using all the latest  
> plugin versions (current default behavior) and then when I see that  
> they all work together have some mechanism to freeze the list and  
> have the current versions (whatever they are) automatically written  
> into my POM without me having to sort through and figure out what  
> the versions are and manually insert them into the POM.  I would  
> want to be able to freeze the list not just at release time but at  
> any arbitrary time to stabilize the development environment for my  
> team.
>
>
> Thanks.
>
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------





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

On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote:
> On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote:
> > For me, I am completely aware that I want to lock *everything* down  
> > (including plugins) to have reproducible builds.  So marketing,  
> > advertising, pleading with us, educating us is not the issue.

> The code in the enforcer plugin can actually extract the versions that  
> were used as part of a build so we could turn this into something  
> people could use. John has also been working on a lifecycle plugin  
> which displays the information about the lifecycle which means we  
> could extract the information from that too and make a descriptor. So  
> we can test different combinations of plugins as they are released and  
> give those combinations to users in some controlled way.

I think the idea of specifying versions in the "super pom" is
pointless. Stability for a given release of maven is not particularly
useful when many users are using different versions of maven to build
something.

It would be much more useful for maven 2.0.9 to simply *warn* when a
plugin is found without a version. That's better than trying to
"advertise" best practice via the maven website. Better yet, have it
fail the build unless some kind of "override" option is present on the
command-line. Isn't that part of what the enforcer plugin actually does?
If so, then why not make that a default plugin in maven 2.0.9, ie bind
it to an appropriate phase by default?

It would be also nice for maven to have the ability to dump the versions
of stuff it uses for any particular build, then allow later runs of
maven to accept that dump-file as input to set the versions. That's a
quick-fix for people who find 2.0.9 reporting errors on their builds due
to incomplete dependency versioning.

I've personally never encountered a situation where one version of a
plugin would not work with some other version of a different plugin.
What I have found difficult is determining whether things *have* all
been locked down or whether something has been missed.

Regards,
Simon


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

[nicolas de loof-3]

Could we add some SHORT meta-data in the POM to point to a maven superPOM
version ?

By default, use the running maven superPOM, but when set, use the expected
superPOM. Based on this, we could build with maven 2.0.10 a project
designed with maven 2.0.9 superPOM.

Nico.


2008/2/9, Brian E. Fox <brianf@...>:

>
>
> >I have to change my vote to -1 :
>
> >Current maven behavior introduces some issues when plugin version is
> not
> >set. Many users got errors with this and learned to use version.
>
> >Having maven super-POM set plugin version will make the build depend on
> >maven version used.
>
> Compare this change to the current behavior. People simply are not
> locking them down either because they don't know or they don't want to
> make huge xmls. (remember I still think locking them down is the right
> way to do it, but apparently the majority of the users don't/won't). So
> if we do nothing, they are just as likely to have un-reproducible builds
> with a later version of maven. And worse, they potentially break across
> developers because their machines have different versions and it changes
> suddenly without them having any interaction.
>
> What you point out is definitely a risk, but I see it as less harmful
> than the current method.
>
> --Brian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Benjamin Bentmann]

> I think the idea of specifying versions in the "super pom" is
> pointless. Stability for a given release of maven is not particularly
> useful when many users are using different versions of maven to build
> something.

I think it's common sense that the proposed lock down in the super POM is
not the final solution and was not intended as such. Reproducible builds
require the user himself to lock the plugin versions in his own (corporate)
POM, nobody else can do this.

The changes to the super POM are all about improving (not solving) the
current situation for Maven 2.0.x. If we can agree on the assumption that
there are less different versions of Maven in use than local repositories
existent among the developers, the additions in the super POM help to
improve build reproducibility.

> It would be much more useful for maven 2.0.9 to simply *warn* when a
> plugin is found without a version. That's better than trying to
> "advertise" best practice via the maven website. Better yet, have it
> fail the build unless some kind of "override" option is present on the
> command-line.

For the sake of backward-compatibility within the 2.0.x development line,
one surely would not want to break the build here.

> What I have found difficult is determining whether things *have* all
> been locked down or whether something has been missed.

You could run
  mvn clean deploy site-deploy -U
and grep for "checking for updates" in the log output.

Regards,


Benjamin Bentmann


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

[Don Brown-2]

On 2/10/08, Jason van Zyl <jason@...> wrote:
> You're asking for a far more complicated solutions to be implemented
> which generally aren't much more helpful. You're also conflating the
> solution with what people should do and what they should actually be
> doing. Yes, people should use versions for their plugins, but in the
> absence of that putting the versions in the POM is the easiest
> solution to provide the most stability, in most cases.

Well said.  I'm really excited to see this discussion and the
generally positive support for the proposal.  Providing stable,
repeatable builds out of the box is such an important feature in a
build tool.  As I understand it, you can still override the plugin
versions in your own POMs, but for the vast Maven newbie public, this
change would go a long ways to meeting expectations.

[shameless bribe] Make this change in 2.x and I'll fix all the issues
remaining for http://jira.codehaus.org/browse/MNG-3379 ... :)

Don

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

[Jason van Zyl-2]

On 9-Feb-08, at 11:55 AM, simon wrote:

>
> On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote:
>> On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote:
>>> For me, I am completely aware that I want to lock *everything* down
>>> (including plugins) to have reproducible builds.  So marketing,
>>> advertising, pleading with us, educating us is not the issue.
>
>> The code in the enforcer plugin can actually extract the versions  
>> that
>> were used as part of a build so we could turn this into something
>> people could use. John has also been working on a lifecycle plugin
>> which displays the information about the lifecycle which means we
>> could extract the information from that too and make a descriptor. So
>> we can test different combinations of plugins as they are released  
>> and
>> give those combinations to users in some controlled way.
>
> I think the idea of specifying versions in the "super pom" is
> pointless. Stability for a given release of maven is not particularly
> useful when many users are using different versions of maven to build
> something.
>
> It would be much more useful for maven 2.0.9 to simply *warn* when a
> plugin is found without a version.

That's what the enforcer plugin can do. Don't expect people to know  
what it is, or what it does initially. You are now a seasoned user,  
and probably version everything. This solution is not for you. For 2.1  
we could make them mandatory, this is a solution to help the  
inexperienced Maven user not get bit in the ass.

This does not negate:
- creating better documentation to get people to lock down their  
versions
- creating better tools to present snippets of version information

But who is going to create those tools? This is an easy fix to provide  
a better situation. Not an ideal situation but I see no downside for  
the average user.

> That's better than trying to
> "advertise" best practice via the maven website. Better yet, have it
> fail the build unless some kind of "override" option is present on the
> command-line. Isn't that part of what the enforcer plugin actually  
> does?
> If so, then why not make that a default plugin in maven 2.0.9, ie bind
> it to an appropriate phase by default?
>
> It would be also nice for maven to have the ability to dump the  
> versions
> of stuff it uses for any particular build, then allow later runs of
> maven to accept that dump-file as input to set the versions. That's a
> quick-fix for people who find 2.0.9 reporting errors on their builds  
> due
> to incomplete dependency versioning.
>
> I've personally never encountered a situation where one version of a
> plugin would not work with some other version of a different plugin.
> What I have found difficult is determining whether things *have* all
> been locked down or whether something has been missed.
>
> Regards,
> Simon
>
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

What matters is not ideas, but the people who have them. Good people  
can fix bad ideas, but good ideas can't save bad people.

-- Paul Graham




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

[Jason van Zyl-2]

On 9-Feb-08, at 12:33 PM, Don Brown wrote:

> On 2/10/08, Jason van Zyl <jason@...> wrote:
>> You're asking for a far more complicated solutions to be implemented
>> which generally aren't much more helpful. You're also conflating the
>> solution with what people should do and what they should actually be
>> doing. Yes, people should use versions for their plugins, but in the
>> absence of that putting the versions in the POM is the easiest
>> solution to provide the most stability, in most cases.
>
> Well said.  I'm really excited to see this discussion and the
> generally positive support for the proposal.  Providing stable,
> repeatable builds out of the box is such an important feature in a
> build tool.  As I understand it, you can still override the plugin
> versions in your own POMs, but for the vast Maven newbie public, this
> change would go a long ways to meeting expectations.
>

This makes the situation better, but still has the potential to hose  
people. It's just less likely that some new users will start with  
2.0.x, then quickly switch to 2.0.x+1 and get nailed. This doesn't  
promote a best practice but goes a step toward keeping the shot gun  
out of peoples' mouthes.

What I will push for in 2.1 is a version requirement in the POM. From  
the command line you'll get the latest. But this is something we never  
should have done, and the auto upgrade was also a mistake. But in the  
short term the downside is acceptable and it's very easy to do.

> [shameless bribe] Make this change in 2.x and I'll fix all the issues
> remaining for http://jira.codehaus.org/browse/MNG-3379 ... :)
>

For the 2.0.x I'm fine with anything there, but for the the separated  
maven-artifact I have asked Greg/Jan (Jetty folks) to help create a  
connector using the Jetty client library that would be optimal for use  
with Maven. They probably have a tad more experience with HTTP then  
any of us and I'm hopeful they come up with an optimal long term  
strategy.

> Don
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

-- Jacques Ellul, The Technological Society




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

[Jason van Zyl-2]

On 9-Feb-08, at 12:31 PM, Benjamin Bentmann wrote:

>> I think the idea of specifying versions in the "super pom" is
>> pointless. Stability for a given release of maven is not particularly
>> useful when many users are using different versions of maven to build
>> something.
>
> I think it's common sense that the proposed lock down in the super  
> POM is not the final solution and was not intended as such.

Exactly, it's a practical means to a short term end that helps with  
the average, new, inexperienced user.

> Reproducible builds require the user himself to lock the plugin  
> versions in his own (corporate) POM, nobody else can do this.
>
> The changes to the super POM are all about improving (not solving)  
> the current situation for Maven 2.0.x. If we can agree on the  
> assumption that there are less different versions of Maven in use  
> than local repositories existent among the developers, the additions  
> in the super POM help to improve build reproducibility.
>
>> It would be much more useful for maven 2.0.9 to simply *warn* when a
>> plugin is found without a version. That's better than trying to
>> "advertise" best practice via the maven website. Better yet, have it
>> fail the build unless some kind of "override" option is present on  
>> the
>> command-line.
>
> For the sake of backward-compatibility within the 2.0.x development  
> line, one surely would not want to break the build here.
>
>> What I have found difficult is determining whether things *have* all
>> been locked down or whether something has been missed.
>
> You could run
> mvn clean deploy site-deploy -U
> and grep for "checking for updates" in the log output.
>
> Regards,
>
>
> Benjamin Bentmann
>
> ---------------------------------------------------------------------
> 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
----------------------------------------------------------

Selfish deeds are the shortest path to self destruction.

-- The Seven Samuari, Akira Kirosawa




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