[
https://jira.codehaus.org/browse/MNG-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333151#comment-333151
]
Karl M. Davis commented on MNG-5434:
------------------------------------
I finally had some time to look at this some more, and it appears that I'd just
chosen a poor version to test against. Here's a summary of my test results:
||Version A||Version B||Latest (Numerically)||Latest
(Lexicographically)||Latest (Maven 3.0.4)||
|1.0.0.0|1.0.0.0.0|(ambiguous)|1.0.0.0.0|1.0.0.0|
|1.0.0|1.0.0.0|(ambiguous)|1.0.0.0|1.0.0|
|1.0.0.100-SNAPSHOT|1.0.0.2-SNAPSHOT|1.0.0.100-SNAPSHOT|1.0.0.100-SNAPSHOT|1.0.0.100-SNAPSHOT|
|2|2.0|(ambiguous)|2.0|2|
|3.4.5.6.7.008|3.4.5.6.7.08|(ambiguous)|3.4.5.6.7.008|3.4.5.6.7.008|
|5.6.7.8-fix1.2|5.6.7.8-fix002|5.6.7.8-fix002|5.6.7.8-fix1.2|5.6.7.8-fix002|
|4.5.6.7.8.9.1|4.5.6.7.8.10|4.5.6.7.8.10|4.5.6.7.8.9.1|4.5.6.7.8.10|
Maven's behavior is as expected in all non-ambiguous cases that I tried. I
would say that the {{1 > 1.0}} logic is surprising, but nonetheless reasonable.
> Maven version ranges do not properly handle versions with more than four
> components
> -----------------------------------------------------------------------------------
>
> Key: MNG-5434
> URL: https://jira.codehaus.org/browse/MNG-5434
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: General
> Affects Versions: 3.0.4
> Environment: Linux 64-bit
> Reporter: Karl M. Davis
>
> When using a version range, e.g. "[1.0-SNAPSHOT,)", versions with more than
> four components are not sorted correctly. For example, "1.0.0.0" will be
> sorted as greater/later than "1.0.0.0.0". However, "1.0.0" will be sorted as
> greater/later than "1.0.0.0".
> The behavior here is a bit odd... all of the maven-metadata-XXX.xml files in
> the local repository will correctly list "1.0.0.0.0" as the "latest" and
> "release" version, but running compile, dependency:tree, etc. will instead
> select "1.0.0.0". Aether API calls are also exhibiting the buggy sorting
> behavior, too.
> I haven't yet tried any debugging to track this down, but I've trolled
> through git and my best guess is that this behavior is related to the version
> of maven-artifact being used. The 2.x releases
> DefaultArtifactVersion.compareTo(...) method does not correctly handle
> versions with more than four components, but the 3.x releases of it do [1].
> Maybe the problem is just that [the compile plugin is still using
> maven-artifact:2.0.9|http://maven.apache.org/plugins/maven-compiler-plugin/dependencies.html]?
> This is hurting us here. While many of our projects use versions with four or
> less components, we follow the [add a version component for branches
> versioning
> strategy|http://janvanbesien.blogspot.com/2009/06/consistent-svn-brach-and-tag-names-for.html]
> to prevent version conflicts between branches. This allows us to use version
> ranges in our POMs, making life a lot easier.
> [1] The following commit seems to be where this was fixed in maven-artifact:
> [maven.git
> beb9d731691beed1b0099a790a8ae1973f55dc0b|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=beb9d731691beed1b0099a790a8ae1973f55dc0b].
> It looks like the code is what was originally proposed in the [Improve
> default support for version
> schemes|http://docs.codehaus.org/display/MAVEN/Versioning] Maven wiki page.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
