RE: [IMPORTANT] Maven 2 Plugin Auto-Versioning Considered Dangerous

[houzecl <ch...@etat.ge.ch>]

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:casey.john.d@gmail.com] 
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

-- 
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org