So, let me see if I understand: - Assigning arbitrary quality levels is hard to do. I agree. - Linking the version selection process to something quantitative like test results and coverage results is better. I also agree but this seems a ways off. The interface between test reporting and whatever sets the metadata used by version selection will have to happen somehow.
Sounds like a case for a plugin perhaps. After the test phase this plugin (tailored to whatever testing system one is using) would make a pass at the test results and then assign a quality attribute in the metadata. Then, during version selection that quality attribute is examined depending on what the user is wanting to select. -----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 4:53 PM To: Maven Developers List Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1 On 1 May 07, at 5:37 PM 1 May 07, Clark, Gil W. wrote: > 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. > Maven has the notion of pluggable version transformations. This is the mechanism which looks at the token "SNAPSHOT" and performs the necessary logic to examine the metadata and retrieve the last built version. It's technically not hard to look at an arbitrary token and perform some logic to change the version that is slotted in. The problem here is not a technical one of allowing any token, the problem is that what these things mean to people and the process they go through to arrive to determine the meaning will be arbitrary. I think what people really want here is "something that has some functional improvements but are binary compatible with what I'm using". What "WORKING", or "RELEASE" means vary. Especially in the case of a release as people currently have different processes. We have already standard testing patterns and surefire, and we are starting to see standard release procedures so what we want to move toward is the use of ranges which would be good but coupled with some criteria for quality. So you would simply say I want [1.0,) which is anything 1.0 or above that 1) is binary compatible with what I used last time (we go and find the last release and see what version was resolved), and 2) has the same or better coverage. This is the only way you can deterministically be safe of picking something further down in a range. Who's going to assign these arbitrary labels to releases? I mean who is doing this for Ivy? This stuff cannot be tacked on by the third party it simply is not scalable. Maven has the social capital (the necessary mass of users doing the same thing) to pull off these coverage and binary compatibility standards to make this transparent. That being said I still think people would benefit more from a daily report produced from a build server that pulled in new versions of dependencies that purport to work and actually run your tests. If successful then you click a button and your POMs are upgrade. The computer should do the crap work. We are really not that far away from something like this. > The hardest part in all this is standardizing on these quality > levels - t Bingo. This can only happen in a community like Maven where we have striven for standard everything from day one because this is the only way these types of things are possible. This will never be possible using Ant with Ivy, it was never the goal of Ant. They might say they can but that will require the addition of everything we already have. Then it will be converging toward what Maven actually is. The key difference is that Maven from day one was designed to have a complete and holistic approach to solving problems like this. For example right now for releases, using the profile we have created, we require PGP signatures, javadocs, sources, and the licenses and notice files are inserted automatically (with the available overriding for cases where the metadata is insufficient). As our profile spreads into common use we can then also mixin Clirr to produce a small file indicating the level of binary compatibility, and a file indicating coverage. Even if this was not done in the original build we can inject those plugins for the release. How? Because all our builds are the same. Intervention on our part, but entirely scalable because of the common structure of our projects. I don't think many people using Maven, let alone detractors understand the power and utility of our model. We let the computer do what it's good at and keep track of these bits. We will just say we want it to work :-) Jason. > hey 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] > > --------------------------------------------------------------------- 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]
