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
