On 01/02/2010, at 10:57 PM, Benjamin Bentmann wrote: > Brett Porter wrote: > >> I'm not that tied to the idea, it was just a thought to avoid the potential >> problem that had been raised by a user. > > Please consider that such a version lockdown is twofold: It not only saves > the user from potential regressions in newer versions but also excludes him > from any bugfixes/improvements made in the newer plugin versions, unless you > are willing to put the update instructions on each and every doc page out > there that mentions the Archetype Plugin.
Yup, I understand it's a tradeoff, and that's why I wanted to be clear it was an exception for Archetype, not other CLI plugins - but I do see your point. > The proper fix for this would be to increase the test coverage for the plugin. Couldn't agree more :) > > The other related issue is RELEASE vs LATEST. When resolving a plugin > version, Maven 2.x prefers LATEST over RELEASE, i.e. Maven 2.x potentially > prefers a SNAPSHOT over a proper release. Yep, when I was proposing this I was under the impression that both snapshots and releases would be regularly obtained. With Maven 3 preferring RELEASE, and with MNG-4554 fixed (thanks!), I see very little need for the exception, so I'll close the issue out. > IIRC, it was an IRC discussion with Arnaud where we seemed to agree that this > behavior is not really helpful to the majority of ordinary users. So this > might be something to review for Maven 2.x as well. I'm not sure what you talked about, but if Arnaud wants to implement it for 2.x that's fine by me. I just don't think it's a 2.2.2 thing, and at this stage we haven't made any plans for a 2.3. I'm still in favour of a 2.3 that provides a "stepping stone" to 3.0 with changes like this, but I'd personally rather focus on 3.0 once we get past the planned releases. - Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
