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