You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Karl M. Davis (JIRA)" <ji...@codehaus.org> on 2013/02/13 20:36:13 UTC
[jira] (MNG-5434) Maven version ranges do not properly handle
versions with more than four components
Karl M. Davis created MNG-5434:
----------------------------------
Summary: 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: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5434) Maven version ranges do not properly handle
versions with more than four components
Posted by "Karl M. Davis (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319656#comment-319656 ]
Karl M. Davis commented on MNG-5434:
------------------------------------
Actually, I was incorrect about Aether: API calls are sorting artifact versions correctly. For example, org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest) is working as expected.
> 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: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira