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