Maven 2 & 3

Problem parsing version ranges

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.6, 2.0.7, 2.0.8, 2.0.9
  • Fix Version/s: 3.0-alpha-1
  • Component/s: Artifacts and Repositories, POM
  • Labels:
    None
  • Environment:
    Linux FC6/ jdk 1.6.0
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

My pom includes the following dependency:

<dependency>
  <groupId>it.unimaticaspa.unique</groupId>
  <artifactId>unilet-core</artifactId>
  <version>[5.0.9.0,5.0.10.0)</version>
  <type>jar</type>
</dependency>

When i try to build the project i get the following stacktrace:

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Unable to parse version '[5.0.9.0,5.0.10.0)' for dependency 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: [5.0.9.0,5.0.10.0)
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Unable to parse version '[5.0.9.0,5.0.10.0)' for dependency 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: [5.0.9.0,5.0.10.0)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.artifact.InvalidDependencyVersionException: Unable to parse version '[5.0.9.0,5.0.10.0)' for dependency 'it.unimaticaspa.unique:unilet-core:jar': Range defies version ordering: [5.0.9.0,5.0.10.0)
        at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:331)
        at org.apache.maven.project.MavenProject.createArtifacts(MavenProject.java:1558)
        at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1236)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
        ... 16 more
Caused by: org.apache.maven.artifact.versioning.InvalidVersionSpecificationException: Range defies version ordering: [5.0.9.0,5.0.10.0)
        at org.apache.maven.artifact.versioning.VersionRange.parseRestriction(VersionRange.java:210)
        at org.apache.maven.artifact.versioning.VersionRange.createFromVersionSpec(VersionRange.java:125)
        at org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:327)
        ... 20 more

It seems that versions are compared as strings, because the problem only comes out comparing versions with different numbers of digits (such as 5.0.9.0 and 5.0.10.0). While comparing 5.0.8.0 with 5.0.9.0 everything is fine.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-2210 Dependency version range picks version 1.7.2-rc1 when specified as [1.8.0.1,)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4899 strange behavior during the dependency resolution

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNG-3518 Handle date qualifier in DefaultArtifactVersion

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Improvement - An improvement or enhancement to an existing feature or task. MNG-5066 Unable to customize Dependencies version ordering while using range in dependency version tag

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Improvement - An improvement or enhancement to an existing feature or task. MNGECLIPSE-281 Version numbers are compared as strings

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-2742 Using a version range in a plugin dependency causes "failure to resolve artifact" error

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. MNG-3526 Small change to artifact version parsing.

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Julian added a comment -

I'm afraid this is the expected behavior for how Maven 2.0.x treats version numbers.

You hit on the problem at the end when you noted "versions are compared as strings." For the versions you cite-5.0.9.0 and 5.0.10.0-maven does compare these as strings and 5.0.9.0 is considered newer than 5.0.10.0. Ergo, the range "[5.0.9.0,5.0.10.0)" is invalid for the same reason "[2,1)" would be: the version on the left is newer than the one on the right.

Here's the ugly details. Maven recognizes versions that match the following pattern:

A.B.C-D or
A.B.C-foo

where:

A is the Major Version,
B is the Minor Version,
C is the Incremental Version (also known as Bug Fix),
D is the Build Number, and
'foo' is the Qualifier.

A, B, C, and D, are compared numerically and the qualifier is a string compare. A version may only have a build number or a qualifier, not both. The numbers are considered zero if not present i.e., 1.1 is the same as 1.1.0 and 1.1-0.

Here's the important part: any version not matching this pattern is treated entirely as a String.

Here is the relevant part of org.apache.maven.artifact.versioning.VersionRange:

if ( upperVersion != null && lowerVersion != null && upperVersion.compareTo( lowerVersion ) < 0 )

{ throw new InvalidVersionSpecificationException( "Range defies version ordering: " + spec ); }

Here is a test using org.apache.maven.artifact.versioning.DefaultArtifactVersion:

public void testMng3010()

{ String s1 = "5.0.9.0"; String s2 = "5.0.10.0"; DefaultArtifactVersion v1 = new DefaultArtifactVersion(s1); DefaultArtifactVersion v2 = new DefaultArtifactVersion(s2); assertTrue( s1.compareTo(s2) > 0 ); // 5.0.9.0 > 5.0.10.0 as Strings ... assertTrue( v1.compareTo(v2) > 0 ); // ... and as maven versions }

If you have control over how this project tracks its version, consider changing it to a more Maven-friendly pattern. If not, you'll have to find another way of dealing with the issue e.g., just picking one and omitting the range entirely.

Show
David Julian added a comment - I'm afraid this is the expected behavior for how Maven 2.0.x treats version numbers. You hit on the problem at the end when you noted "versions are compared as strings." For the versions you cite- 5.0.9.0 and 5.0.10.0 -maven does compare these as strings and 5.0.9.0 is considered newer than 5.0.10.0. Ergo, the range "[5.0.9.0,5.0.10.0)" is invalid for the same reason "[2,1)" would be: the version on the left is newer than the one on the right. Here's the ugly details. Maven recognizes versions that match the following pattern: A.B.C-D or A.B.C-foo where: A is the Major Version, B is the Minor Version, C is the Incremental Version (also known as Bug Fix), D is the Build Number, and 'foo' is the Qualifier. A, B, C, and D, are compared numerically and the qualifier is a string compare. A version may only have a build number or a qualifier, not both. The numbers are considered zero if not present i.e., 1.1 is the same as 1.1.0 and 1.1-0. Here's the important part: any version not matching this pattern is treated entirely as a String. Here is the relevant part of org.apache.maven.artifact.versioning.VersionRange: if ( upperVersion != null && lowerVersion != null && upperVersion.compareTo( lowerVersion ) < 0 ) { throw new InvalidVersionSpecificationException( "Range defies version ordering: " + spec ); } Here is a test using org.apache.maven.artifact.versioning.DefaultArtifactVersion: public void testMng3010() { String s1 = "5.0.9.0"; String s2 = "5.0.10.0"; DefaultArtifactVersion v1 = new DefaultArtifactVersion(s1); DefaultArtifactVersion v2 = new DefaultArtifactVersion(s2); assertTrue( s1.compareTo(s2) > 0 ); // 5.0.9.0 > 5.0.10.0 as Strings ... assertTrue( v1.compareTo(v2) > 0 ); // ... and as maven versions } If you have control over how this project tracks its version, consider changing it to a more Maven-friendly pattern. If not, you'll have to find another way of dealing with the issue e.g., just picking one and omitting the range entirely.
Hide
Permalink
Gabriele Contini added a comment -

Thank you for the long explanation. I'll use a "maven friendly" version scheme in my project.

Show
Gabriele Contini added a comment - Thank you for the long explanation. I'll use a "maven friendly" version scheme in my project.
Hide
Permalink
Mark Hobson added a comment -

Also see Kenney's proposal for better version number handling in 2.1:
http://docs.codehaus.org/display/MAVEN/Versioning

Show
Mark Hobson added a comment - Also see Kenney's proposal for better version number handling in 2.1: http://docs.codehaus.org/display/MAVEN/Versioning
Hide
Permalink
Herve Boutemy added a comment -

default version comparison has been improved in artifact 3.0-SNAPSHOT r656775 (15/5/2008).

Show
Herve Boutemy added a comment - default version comparison has been improved in artifact 3.0-SNAPSHOT r656775 (15/5/2008).

People

  • Assignee:
    Herve Boutemy
    Reporter:
    Gabriele Contini
Vote (1)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: