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 <[EMAIL PROTECTED]>:
+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 <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
