2009/10/16 Peter Janes <[email protected]> > On 16/10/09 11:47 AM, Stephen Connolly wrote: > >> 2009/10/16 Peter Janes<[email protected]> >> >> However, I'm not aware of any released version of Maven or any plugin >>> that >>> actually treats dependencies this way; Mercury, tested through >>> versions-maven-plugin, doesn't appear to either. (But I'd love to be >>> proven >>> wrong!) >>> >> >> versions-maven-plugin does not use mercury to resolve the artifacts, it >> only >> uses the same comparison rule as mercury uses... artifact resolution is >> provided by the maven core that you are running v-m-p with. >> > > Ah, then I did misunderstand the purpose of using the mercury > comparisonMethod. I thought that display-dependency-updates (for example) > would find all of the available versions for the artifact, then compare them > using the Mercury (or Maven, or numeric) rules and find what those rules > considered to be the newest one; now I'm not sure what it's supposed to do > or how. >
The point of display-dependency-updates is to display the updates of your dependencies. The problem is deciding what is an update. If everyone followed the Maven 2 rules for version numbers (which are quite strict and inflexible) then you'd be fine... But you have some people that have to follow a corporate policy w.r.t. version numbers. For example, AT&T had/has a policy of using something like 5 (or 6 if you talk to some ex-AT&T companies) segments for their version numbers... so that their version numbers should look something like 1.0.0.0.1, 2.1.0.5.7 Under the Maven 2 version number rules, that is an invalid version number, and invalid version numbers are treated as being entirely a qualifier, so that... in terms of maven version comparison, 1.0.0.0.1 is effectively 0.0.0-1.0.0.0.1, and 2.1.0.5.7 is 0.0.0-2.1.0.5.7 This gives the rather strange situation whereby, 0.0.1 is newer than 2.1.0.5.7 and 2.1.0.5.7 is not in the range [2.0,3.0) Another example is RedHat artifacts (which includes JBoss). These tend to be numbered with things like 4.2.3.GA, 4.2.3.SP1, etc again, all qualifier, so that 4.3.2.GA is effectively (in Maven 2 version comparison rules) behaving like 0.0.0-4.3.2.GA Most people think that therefore, the Maven 2 rules are "stupid". v-m-p therefore provides a mechanism to define groupIds which are not following the Maven 2 version rules... i.e. the rule-set.xml file ( http://mojo.codehaus.org/versions-maven-plugin/version-rules.html) It is only a hack until we sort out some versioning scheme metadata storage mechanism... if we take the above examples, we might construct a ruleset like so: <ruleset comparisonMethod="maven"> <rules> <rule groupId="com.att" comparisonMethod="numeric"/> <rule groupId="com.lucent" comparisonMethod="numeric"/> <rule groupId="com.alcatel-lucent" comparisonMethod="numeric"/> <rule groupId="com.belllabs" comparisonMethod="numeric"/> <rule groupId="com.avaya" comparisonMethod="numeric"/> <rule groupId="com.lsi" comparisonMethod="numeric"/> <!-- etc, keep following that AT&T history --> <rule groupId="com.redhat" comparisonMethod="mercury"/> <rule groupId="com.jboss" comparisonMethod="mercury"/> <rule groupId="org.jboss" comparisonMethod="mercury"/> <rule groupId="org.hibernate" comparisonMethod="mercury"/> <!-- etc, keep following those RedHat mergers and aquisitions --> </rules> </ruleset> > > That does explain why I had a hard time following the source to debug the > processing of LATEST/RELEASE from the repository metadata, though: it was > never there! :) > > > -- > Sometimes the Universe needs a change of perspective. > --J. Michael Straczynski > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
