Maven
  1. Maven
  2. MNG-3010

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
    • 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

          Activity

          Hide
          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
          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
          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
          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
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: