That makes a lot of sense.
On 4/12/07, Peter Nilsson <[EMAIL PROTECTED]> 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]
