The enforcer plugin will hopefully help to have better control on plugin version with the "Require Plugin Versions". I tried to use it. (because I had myself to switch back to previous assembly version: I suddenly got a ".dir" addition to the directories created by assembly )
However this "Require Plugin Versions" seems only available in 1.0-alpha-4-SNAPSHOT (I am currently using 1.0-alpha-3) Totally agree that in corporate environment we must have a very close control on the plugins used. Christian-Luc Peter Nilsson-2 wrote: > > The auto-resolver is a pain when using Maven in a corporate environment > when > there is a strong requirement to be able to reproduce a build. As > mentioned > by others one of the problems is to know which plugins are used and thus > need to have their version locked down. > > I would prefer a property (command line or in pom) that disabled the > auto-resolver and made a build fail if not all versions were explicit. > Then you could choose to use auto-resolver or not, depending on your > priorities on ease of use versus reproducibility. > > Peter > > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: den 11 april 2007 18:19 > To: Maven Users List > Subject: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous > > Hi everyone, > > I wanted to send out a quick email to let everyone know about some > discussion that's been taking place on the developers' list regarding > plugin > versions. In trying to release the 2.2-beta-1 version of the assembly > plugin, it became apparent that this version fixes some bugs in the > 2.1version that don't necessarily look like bugs. All discussion about > what is > or is not a bug aside, the discussion raises an interesting point: if you > do > not specify a version for the plugins in your POMs, a situation can arise > where Maven will seamlessly resolve an incompatible plugin version and try > to use it. > > Here's an example: > > Say I create a project that uses the assembly plugin, version 2.1. My > assembly descriptor takes advantage of a bug in this version where the > explicit inclusion of a .tar.gz dependency does not have its own > transitive > dependencies included, unless they too are explicitly included. This is > incorrect, because there is no ArtifactHandler that specifies that the > .tar.gz file contains its own dependencies (so, therefore, should not have > its transitive dependencies resolved, much less factored into > inclusion/exclusion)...also, from a semantics point of view, Maven's other > dependency usages indicate that specifying a dependency implies that > you're > specifying that dependency's transitive dependencies...the whole sub-graph > should be handled, in other words. > > Having created this project with its assembly descriptor, but WITHOUT A > VERSION IN THE ASSEMBLY PLUGIN DECLARATION, I commit my project. Now, some > time later, after the next version of the assembly plugin fixes this bug, > a > user comes along. He installs Maven, checks out my project, and tries to > build. Without a single line of code changing in my project, the build > fails, because his Maven instance resolved the plugin to the newer > version. > I cannot replicate his failed build, because my assembly-plugin version > had > not been updated (I didn't use -U during the build). > > > You can say that the next version should make an effort to support users > exploiting bugs like this, and you can say that plugins need to deprecate > and gradually move away from behavior that has turned out to be bad > design, > counter-intuitive, etc. To this extent, you could argue that the next > release that "fixed" the bug above should have made an allowance for this > scenario. > > However, consider what happens if the plugin has been released several > times...say that the newest version is actually 3.1 now. In this scenario, > it's entirely reasonable to think that the developers have provided a long > migration period - along with deprecation warnings - that spanned multiple > versions, and then finally dropped the support for this broken > configuration. However, Maven has no idea of any of this, and the > aforementioned setup will break. > > All of this can be avoided by simply being careful about evaluating, then > migrating, to new plugin versions in a very deliberate fashion. If you > take > a look at the world of systems administration, you see this sort of thing > everywhere. People take enough time to pour over release notes and > determine > whether the new version is likely to wreck the existing setup. The same > should go for building a reproducible build infrastructure. > > I'm going to start a discussion on the developers' for getting rid of the > plugin-version auto-resolver in Maven 2.1 immediately, to start pushing > the > tools down this path. However, it will make everyone's lives easier to > start > the process now. Please, take a moment and put the plugin versions into > your > POMs. > > Thanks, > > John > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/-IMPORTANT--Maven-2-Plugin-Auto-Versioning-Considered-Dangerous-tf3560426s177.html#a13043316 Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]