Maven
  1. Maven
  2. MNG-2742

Using a version range in a plugin dependency causes "failure to resolve artifact" error

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 2.0.4
    • Fix Version/s: None
    • Component/s: Dependencies
    • Labels:
      None
    • Environment:
      Windows XP SP2, java version "1.5.0_08"
    • Complexity:
      Intermediate
    • Number of attachments :
      2

      Description

      If I declare a dependency in a plugin using an exact version, Maven correctly resolves the artifact. If, however, I change the dependency's version to a version range, Maven no longer resolves the artifact. I'm using the very same artifact and version range in my project's dependencies and everything works ok. See my attached pom.xml file for details, in particular, the comments "<Unable to render embedded object: File (-- Using version range here ok -->" and "<) not found.-- Can't use version range here! -->".

      I am using the "major.minor.revision-buildNumber" version string syntax as described on the wiki.

      1. mvn.txt
        24 kB
        Matthew Adams
      2. pom.xml
        4 kB
        Matthew Adams

        Issue Links

          Activity

          Hide
          Matthew Adams added a comment -

          NB: JIRA interpreted XML comments somehow. Here's the summary again:

          If I declare a dependency in a plugin using an exact version, Maven correctly resolves the artifact. If, however, I change the dependency's version to a version range, Maven no longer resolves the artifact. I'm using the very same artifact and version range in my project's dependencies and everything works ok. See my attached pom.xml file for details, in particular, the comments "Using version range here ok" and "Can't use version range here!".

          I am using the "major.minor.revision-buildNumber" version string syntax as described on the wiki.

          Show
          Matthew Adams added a comment - NB: JIRA interpreted XML comments somehow. Here's the summary again: If I declare a dependency in a plugin using an exact version, Maven correctly resolves the artifact. If, however, I change the dependency's version to a version range, Maven no longer resolves the artifact. I'm using the very same artifact and version range in my project's dependencies and everything works ok. See my attached pom.xml file for details, in particular, the comments "Using version range here ok" and "Can't use version range here!". I am using the "major.minor.revision-buildNumber" version string syntax as described on the wiki.
          Hide
          Matthew Adams added a comment -

          Attached is the output of running "mvn -X package" using the version range.

          Show
          Matthew Adams added a comment - Attached is the output of running "mvn -X package" using the version range.
          Hide
          Matthew Adams added a comment -
          Show
          Matthew Adams added a comment - FYI, the version range string format information came from these spots on the wiki: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution and http://docs.codehaus.org/display/MAVEN/Extending+Maven+2.0+Dependencies
          Hide
          Matthew Adams added a comment -

          I just noticed that the same problem exists when building my Maven2 plugin as well if I declare a dependency on a version range:

          In my plugin's pom.xml:
          ...
          <dependencies>
          <dependency>
          <groupId>com.xcalia</groupId>
          <artifactId>xic</artifactId>
          <version>[4.3.1-1231,)</version>
          </dependency>
          ...

          Here is the log, starting with the error:

          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Failed to resolve artifact.

          No versions are present in the repository for the artifact with a range [4.3.1-1231,)
          com.xcalia:xic:jar:null

          from the specified remote repositories:
          central (http://repo1.maven.org/maven2)

          [INFO] ------------------------------------------------------------------------
          [DEBUG] Trace
          org.apache.maven.lifecycle.LifecycleExecutionException: No versions are present in the repository for the artifact with a range [4.3.1-1231,)
          com.xcalia:xic:jar:null

          from the specified remote repositories:
          central (http://repo1.maven.org/maven2)

          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
          at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
          at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
          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:585)
          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.artifact.versioning.OverConstrainedVersionException: No versions are present in the repository for the artifact with a range [
          1231,)
          com.xcalia:xic:jar:null

          from the specified remote repositories:
          central (http://repo1.maven.org/maven2)

          at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:253)
          at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67)
          at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223)
          at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211)
          at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182)
          at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117)
          at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
          ... 16 more

          Show
          Matthew Adams added a comment - I just noticed that the same problem exists when building my Maven2 plugin as well if I declare a dependency on a version range: In my plugin's pom.xml: ... <dependencies> <dependency> <groupId>com.xcalia</groupId> <artifactId>xic</artifactId> <version>[4.3.1-1231,)</version> </dependency> ... Here is the log, starting with the error: [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [4.3.1-1231,) com.xcalia:xic:jar:null from the specified remote repositories: central ( http://repo1.maven.org/maven2 ) [INFO] ------------------------------------------------------------------------ [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: No versions are present in the repository for the artifact with a range [4.3.1-1231,) com.xcalia:xic:jar:null from the specified remote repositories: central ( http://repo1.maven.org/maven2 ) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:551) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:585) 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.artifact.versioning.OverConstrainedVersionException: No versions are present in the repository for the artifact with a range [ 1231,) com.xcalia:xic:jar:null from the specified remote repositories: central ( http://repo1.maven.org/maven2 ) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:253) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:67) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more
          Hide
          Yves Van Steen added a comment -

          I'm seeing the same thing and l'm using the latest maven release (2.0.6).

          Show
          Yves Van Steen added a comment - I'm seeing the same thing and l'm using the latest maven release (2.0.6).
          Hide
          EM-SNAPSHOT-33 added a comment -

          I'm seeing the same thing while trying to resolve japserreport (on sub-dependency <commons-beanutils>) and l'm using the latest maven release after upgrading (2.0.6)

          Show
          EM-SNAPSHOT-33 added a comment - I'm seeing the same thing while trying to resolve japserreport (on sub-dependency <commons-beanutils>) and l'm using the latest maven release after upgrading (2.0.6)
          Hide
          Paul Smith added a comment -

          There's an example project attached to MNG-2906 which demonstrates the problem, but you need to remove your locally installed commons-collections 2.1 from your repo to flush out the problem.

          Show
          Paul Smith added a comment - There's an example project attached to MNG-2906 which demonstrates the problem, but you need to remove your locally installed commons-collections 2.1 from your repo to flush out the problem.
          Hide
          Mirko Raner added a comment -

          We are currently struggling with similar issues, which, in our case, seem to be related to MNG-3518. The problem occurs only when version ranges are used and the plugin versions use the "major.minor.revision-buildNumber" format (i.e., an additional build qualifier that is separated by a dash and possibly starts with a non-numeric character). I was just wondering whether the issues are related; maybe MNG-2742 is even a duplicate of MNG-3518?
          Anyway, I just wanted to make a note of a possible relation/duplication here...

          Show
          Mirko Raner added a comment - We are currently struggling with similar issues, which, in our case, seem to be related to MNG-3518 . The problem occurs only when version ranges are used and the plugin versions use the "major.minor.revision-buildNumber" format (i.e., an additional build qualifier that is separated by a dash and possibly starts with a non-numeric character). I was just wondering whether the issues are related; maybe MNG-2742 is even a duplicate of MNG-3518 ? Anyway, I just wanted to make a note of a possible relation/duplication here...
          Hide
          Richard Vowles added a comment -

          This has been true since 2.0.4? You have to be kidding! I am using 3.0.3 and it is still broken!

          Show
          Richard Vowles added a comment - This has been true since 2.0.4? You have to be kidding! I am using 3.0.3 and it is still broken!
          Hide
          Conny Kreyssel added a comment -

          @all:

          This is more a generic question.

          All build system should be able to get every time the same output for the same input. In maven, your maven project (the call chain of maven plugins) should produce the same output for the same POM - today and in future. But if you be able to set a version range for maven plugins you do not know how a old build act with new plugins. Possibly you get errors if a required plugin parameter is not set and so on.

          In maven 3.0 you get a warning message if you do not have set a plugin version, in 3.1 mabe it stop building.

          Show
          Conny Kreyssel added a comment - @all: This is more a generic question. All build system should be able to get every time the same output for the same input. In maven, your maven project (the call chain of maven plugins) should produce the same output for the same POM - today and in future. But if you be able to set a version range for maven plugins you do not know how a old build act with new plugins. Possibly you get errors if a required plugin parameter is not set and so on. In maven 3.0 you get a warning message if you do not have set a plugin version, in 3.1 mabe it stop building.
          Hide
          Arnaud Heritier added a comment -

          Same thing here with Maven 3.0.3

          Show
          Arnaud Heritier added a comment - Same thing here with Maven 3.0.3
          Hide
          Markus KARG added a comment -

          I understand that for stable builds, it is necessary to give the exact versions of each plugin. But in some cases this argument is just ridiculous. For example: If I want my code to compile using Java 1.5, I just omit any configuration in the pom.xml and everything is fine. Actually I do not tell Maven 3.0.3 which plugin to use then, nor its version. But as soon as I want to tell the compiler that my code uses Java 6 syntax, I have to give the exact bug fix number (2.3.2):

          <plugin>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>2.3.2</version>
          <configuration>
          <source>1.6</source>
          <target>1.6</target>
          </configuration>
          </plugin>

          This is totally ridiculous as I STILL do not care about the name or version of the plugin, but NOW I must not only tell that it is named maven-compiler-plugin or that I want release 2.3 to be used, but ALSO that the exact bug fix 2.3.2 is to be used. I even more CANNOT tell the system anymore that I want to get the latest compiler plugin bug fix as now the version is fixed (this would have worked well without this config entry, as soon as I download a later Maven ZIP for example).

          So in fact, the force to write the version leads to WORSE results as one will not get the latest bug fixes then!

          So please, make "use the latest bug fix" the default and don't force people to check for later release numbers manually...! It is MORE essential to get IMPROVED plugins and LESS essential to have THE SAME each time. BTW, if that policy really leads to more unstable results, then the plugin authors have done something REALLY wrong...!

          Show
          Markus KARG added a comment - I understand that for stable builds, it is necessary to give the exact versions of each plugin. But in some cases this argument is just ridiculous. For example: If I want my code to compile using Java 1.5, I just omit any configuration in the pom.xml and everything is fine. Actually I do not tell Maven 3.0.3 which plugin to use then, nor its version. But as soon as I want to tell the compiler that my code uses Java 6 syntax, I have to give the exact bug fix number (2.3.2): <plugin> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin> This is totally ridiculous as I STILL do not care about the name or version of the plugin, but NOW I must not only tell that it is named maven-compiler-plugin or that I want release 2.3 to be used, but ALSO that the exact bug fix 2.3.2 is to be used. I even more CANNOT tell the system anymore that I want to get the latest compiler plugin bug fix as now the version is fixed (this would have worked well without this config entry, as soon as I download a later Maven ZIP for example). So in fact, the force to write the version leads to WORSE results as one will not get the latest bug fixes then! So please, make "use the latest bug fix" the default and don't force people to check for later release numbers manually...! It is MORE essential to get IMPROVED plugins and LESS essential to have THE SAME each time. BTW, if that policy really leads to more unstable results, then the plugin authors have done something REALLY wrong...!
          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
          Hide
          Jason van Zyl added a comment -

          Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

          Show
          Jason van Zyl added a comment - Please refer to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 if you're wondering why this issue was closed out.

            People

            • Assignee:
              Unassigned
              Reporter:
              Matthew Adams
            • Votes:
              17 Vote for this issue
              Watchers:
              21 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: