From a user's Point of View it seems only logical to me that the
lifecycle defines which versions of the Plugins should Be used. The
super pom is no help
Von meinem iPod gesendet
Am 18.11.2009 um 11:58 schrieb "Benjamin Bentmann" <benjamin.bentm...@udo.edu
>:
Brian Fox wrote:
Second, I always subscribe to the theory that "closest" wins.
[...] I think in this case, the pom is
"closer" than the lifecycle and therefore it should win as is
happening in the 3.x case.
I agree, it's simply a matter of giving the build engineer control
over his build.
Still, the particular use case sketched by Sebastian or at least
part of looks valid to me. Imagine a minimal POM (i.e. without
parents) that uses his custom lifecycle mapping. Because we define
some plugin versions in the super POM's plugin management, this
build will
a) observe some plugin versions from the lifecycle mapping being
respected but others not (-> confusion)
b) require additional XML in form of plugin management to eventually
enforce the desired plugin version to make the lifecycle mapping
work as originally designed (-> overhead)
So for this case, the super POM looks more like an obstacle to me.
But AFAIR, we introduced plugin versions in the super POM for just
one reason, namely to provide versions for the plugins used by the
built-in lifecycle mappings. So how about if we removed the entire
plugin management from the super POM and instead specified the
plugin versions directly in the lifecycle mappings?
Apparently, this change would make custom lifecycle mappings that
don't specify plugin versions subject to automatic plugin version
resolution as in Maven 2.0.8- unless the consuming POM (or its
parents) locked the version down. On the hand, Maven 3 will report
this situation as a prominent warning and we preach locking down
plugin versions for some time now.
WDYT?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
