I know I'm getting into iffy territory here and my thoughts on this were kind of rejected on the users list but I think that if the version selection algorithm were to include some sort of quality identifier it would solve some of these problems.
The idea here is that some folks are going to want "latest" regardless of the quality of the latest while others are going to want the latest, highest quality release of a plug-in or component. This can be used in conjunction with a version range. So I could say <version>[1.0-STABLE, 2.0-STABLE)</version> and I'd only get stable releases. Or I could say <version>[1.0-WORKING, 2.0-STABLE)</version> and I'd get defaulted to STABLE as long as there is a stable version within the numeric range or if none exists I'd get WORKING if a version at that quality level falls in the range. Or I could say <version>WORKING</version> if I only want the absolute latest working version of a component - kind of like SNAPSHOT. This allows a POM to be targeted at a particular level of quality while still leaving it open to select from a range of versions. For final releases of a project good practice dictates the version numbers be locked down for all dependencies. That does mean modifying the POM but that seems unavoidable. Of course, there may be multiple levels of quality like WORKING, TESTED, FOO, RELEASE, etc. This is the way Ivy works. The hardest part in all this is standardizing on these quality levels - they can be dynamic - specified in the settings file or top level POM... -----Original Message----- From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 1:36 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 Le mardi 1 mai 2007, Tomasz Pik a écrit : > On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote: > > Le mardi 1 mai 2007, Jerome Lacoste a écrit : > > > Maybe there could be an easy way to let users use the latest ? > > > maybe something like > > > mvn -L ... ( L for latest) > > > that would ignore all specified versions, without requiring a POM > > > change ? Maybe too radical. > > > > such a LATEST option would be very usefull, not only for plugins but > > for every dependencies, to do regression testing against latest > > development version of everything. It would be like if Gump was > > integrated into > > Maven: > > http://gump.apache.org/ > > > > I think we would need to differentiate plugin latest from > > dependencies latest. > > This LATEST thing is already in jira: > http://jira.codehaus.org/browse/MNG-2431 And I think it would be very > useful, both for plugins and for 'normal dependencies'. not exactly: - LATEST STABLE is not LATEST : LATEST doesn't try to differentiate STABLE or not, just get any change to check ASAP if it breaks something - "mvn -L" is on the command line, not in the pom : the pom refers to chosen versions, for normal builds, but "mvn -L" is for continuous builds, overriding chosen versions of the pom, to check if a dependency has an evolution that will break something. The artifact built with "mvn -L" is not intended for use, but only as a pro-active test against dependencies evolution > > Regards, > Tomek > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
