[
http://jira.codehaus.org/browse/MNG-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3046:
------------------------------
Component/s: (was: Artifacts)
Artifacts and Repositories
> DefaultArtifactVersion compareTo misbehaves regarding buildNumber 0
> -------------------------------------------------------------------
>
> Key: MNG-3046
> URL: http://jira.codehaus.org/browse/MNG-3046
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 2.0.6
> Reporter: David Julian
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: MNG-3046-maven-artifact.patch
>
>
> The implementation of Comparable.compareTo(Object) is faulty regarding the
> handling of version numbers where a build number is present but zero. Here's
> a unit test to demonstrate:
> DefaultArtifactVersion v1 = new DefaultArtifactVersion("2.0");
> DefaultArtifactVersion v2 = new DefaultArtifactVersion("2.0-0");
> DefaultArtifactVersion v3 = new DefaultArtifactVersion("2.0-alpha1");
>
> // v1 and v2 are equal
> assertTrue( v1.compareTo(v2) == 0 );
> assertTrue( v2.compareTo(v1) == 0 );
>
> // v1 is newer than v3
> assertTrue( v1.compareTo(v3) > 0 );
> assertTrue( v3.compareTo(v1) < 0 );
>
> // ergo, v2 should also be newer than v3
> assertTrue( v2.compareTo(v3) > 0 ); // FAILS!! returns 0 (equal)
> assertTrue( v3.compareTo(v1) < 0 ); // succeeds
> This test demonstrates this behavior violates symmetry and transitivity.
> Luckily, the fix is easy. A small change to the compareTo method to consider
> qualifiers before build numbers relieves this issue. I have a patch that
> I'll submit as soon as I have the issue number.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
