I think it's more complicated than just removing that.
Firstly, large numbers of command line plugins will stop working.
Secondly, we need to provide a solution for implied plugins (we can
set the version in the lifecycle and then let the user give
pluginManagement to override it, but I'd like to see plugin 'packs'
as a better solution to reduce the amount of configuration needed).
Thirdly, we need to think carefully about the impact on existing
builds. We're not just impacting the people that wrote the build - we
impact the random people that grab a project and unwittingly try and
build it with 2.1 not knowing the author never tested that, and get
the bad experience.
I'm still in favour of a compatibility mode that can be driven by the
prerequisites or the modelVersion. I say let people use the
dependency plugin now to start fixing their builds, but for 2.1 let
them make the conscious decision to move up to this.
- Brett
On 12/04/2007, at 2:54 AM, John Casey wrote:
Hi everyone,
I'd like to make sure we're all on the same page with the plugin
auto-version resolution stuff that we've been discussing lately (on
the
assembly-plugin vote thread, for one thing). I think it's clear
that we
cannot continue to allow Maven to resolve RELEASE or LATEST meta-
versions
for plugins any more. I'd actually argue that this is bad practice
for ANY
artifact that is to be resolved, including site skins, etc. since
it kills
our ability to deprecate features.
I'd like to completely remove this from the DefaultPluginManager in
trunk,
so we can start moving away from this practice immediately.
I guess this is an informal vote on the subject, but I wanted to get
everyone's opinions before I move on it, since it's a fairly important
change.
Here's my +1.
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
