Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-285

Unresolved test-jar dependency during release

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0-beta-4
    • Fix Version/s: None
    • Component/s: prepare
    • Labels:
      None
    • Environment:
      Maven version: 2.0.7
      Java version: 1.5.0_07
      OS name: "mac os x" version: "10.4.10" arch: "i386"
    • Number of attachments :
      1

      Description

      I have a multi-module project where one project produces a normal jar and a test-jar (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html). Another submodule has a test scoped dependency on the test-jar from the first submodule. For example, this is the structure and produced artifacts for a small sample (attached) I built to reproduce this behavior:

      release-test-jar (parent project)
      project-with-test-jar (submodule)
      => project-with-test-jar-1.0.jar
      => project-with-test-jar-1.0-tests.jar
      project-using-test-jar (submodule)
      => project-user-test-jar-1.0.jar

      When I run a 'clean install' the build succeeds. However, when I run a 'release:prepare' the build fails with the following error:

      1 required artifact is missing.

      for artifact:
      com.rfc:project-using-test-jar:jar:1.1

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

      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
      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:280)
      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.resolver.MultipleArtifactsNotFoundException: Missing:
      ----------
      1) com.rfc:project-with-test-jar:test-jar:tests:1.1

      Try downloading the file manually from the project website.

      Then, install it using the command:
      mvn install:install-file -DgroupId=com.rfc -DartifactId=project-with-test-jar \
      -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file
      Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=com.rfc -DartifactId=project-with-test-jar \
      -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file \
      -Durl=[url] -DrepositoryId=[id]

      Path to dependency:
      1) com.rfc:project-using-test-jar:jar:1.1
      2) com.rfc:project-with-test-jar:test-jar:tests:1.1

      ----------
      1 required artifact is missing.

      for artifact:
      com.rfc:project-using-test-jar:jar:1.1

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

      at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305)
      at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272)
      at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238)
      at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397)
      at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)

      Judging from the stack trace this problem seems to occur during dependency resolution as is declared PrepareReleaseMojo with the annotation "@requiresDependencyResolution test".

        Issue Links

          Activity

          Paul Gier made changes -
          Field Original Value New Value
          Link This issue depends upon MNG-2277 [ MNG-2277 ]
          Hide
          Paul Gier added a comment -

          Since the prepare mojo uses @aggregator and @requiresDependencyResolution, it runs into the same problem that occurs in some of the other plugins.

          Show
          Paul Gier added a comment - Since the prepare mojo uses @aggregator and @requiresDependencyResolution, it runs into the same problem that occurs in some of the other plugins.
          Paul Gier made changes -
          Link This issue depends upon MJAR-75 [ MJAR-75 ]
          Hide
          Paul Gier added a comment -

          I guess I was way off with my first attempt at tracking this issue down. Looks like the actual cause is a bug in the jar plugin setting the wrong type on the attached artifact. That's why maven can't resolve the test jar dependency.

          Show
          Paul Gier added a comment - I guess I was way off with my first attempt at tracking this issue down. Looks like the actual cause is a bug in the jar plugin setting the wrong type on the attached artifact. That's why maven can't resolve the test jar dependency.
          brianfox brianfox made changes -
          Link This issue depends upon MNG-2277 [ MNG-2277 ]
          Hide
          Kevin Wilson added a comment -

          found that running the following sequence works around the dependency:
          mvn release:prepare

          1. results in failure
            mvn install
            mvn release:prepare
          2. This time the prepare finishes and checks in the modified pom.xml.
          Show
          Kevin Wilson added a comment - found that running the following sequence works around the dependency: mvn release:prepare results in failure mvn install mvn release:prepare This time the prepare finishes and checks in the modified pom.xml.
          Hide
          Jim Cushing added a comment - - edited

          I think the documentation at http://maven.apache.org/guides/mini/guide-attached-tests.html is incorrect with regards to the classifier. See MNG-3350 ( http://jira.codehaus.org/browse/MNG-3350 ), which might be related.

          Show
          Jim Cushing added a comment - - edited I think the documentation at http://maven.apache.org/guides/mini/guide-attached-tests.html is incorrect with regards to the classifier. See MNG-3350 ( http://jira.codehaus.org/browse/MNG-3350 ), which might be related.
          Paul Gier made changes -
          Fix Version/s 2.0-beta-8 [ 13812 ]
          Hide
          Paul Gier added a comment -

          I believe this issue is now fixed with the release of the maven jar plugin 2.2.

          Show
          Paul Gier added a comment - I believe this issue is now fixed with the release of the maven jar plugin 2.2.
          Paul Gier made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 2.0-beta-8 [ 13812 ]
          Fix Version/s 2.0 [ 12571 ]
          Resolution Fixed [ 1 ]
          Hide
          Krasimir Chobantonov added a comment -

          The issue is still present and this only happens when I'm trying to release the project - the building of the project is fine.

          Maven : version 2.0.8
          maven jar plugin : version 2.2
          maven release plugin : version 2.0-beta-7

          java version "1.5.0_15"
          Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
          Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing)

          The workaround using mvn clean install works but this can't be performed by continuum server automatically.

          Show
          Krasimir Chobantonov added a comment - The issue is still present and this only happens when I'm trying to release the project - the building of the project is fine. Maven : version 2.0.8 maven jar plugin : version 2.2 maven release plugin : version 2.0-beta-7 java version "1.5.0_15" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04) Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing) The workaround using mvn clean install works but this can't be performed by continuum server automatically.
          Paul Gier made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Hide
          Valerio Schiavoni added a comment -

          I get the same problema s Krasmir. The workaround proposed works fine, but with inhibits CI.

          Show
          Valerio Schiavoni added a comment - I get the same problema s Krasmir. The workaround proposed works fine, but with inhibits CI.
          Hide
          Damir Malenicic added a comment - - edited

          I've got the same problem with <classifier>sources</classifier> so it might be the generic classifier handling problem within the release plug-in

          Maven version 2.0.9
          Maven release plug-in version : 2.0-beta-7

          Show
          Damir Malenicic added a comment - - edited I've got the same problem with <classifier>sources</classifier> so it might be the generic classifier handling problem within the release plug-in Maven version 2.0.9 Maven release plug-in version : 2.0-beta-7
          Hide
          Basil James Whitehouse III added a comment -

          I found a workaround to this based on an unrelated hint in this thread: instead of using a classifier use a type of test-jar in the dependency declaration. E.g:

                  <dependency>
                      <groupId>com.company.project</groupId>
                      <artifactId>core</artifactId>
                      <!--<classifier>tests</classifier>-->
                      <type>test-jar</type>
                      <scope>test</scope>
                  </dependency>
          
          Show
          Basil James Whitehouse III added a comment - I found a workaround to this based on an unrelated hint in this thread : instead of using a classifier use a type of test-jar in the dependency declaration. E.g: <dependency> <groupId>com.company.project</groupId> <artifactId>core</artifactId> <!--<classifier>tests</classifier>--> <type>test-jar</type> <scope>test</scope> </dependency>
          Hide
          Basil James Whitehouse III added a comment -

          Oddly this issue doesn't happen when running a dry run of release:perform (e.g. mvn release:perform -DdryRun=true). This makes it awkward to verify fixes since a real release:prepare has to be performed and that will modify your poms which have to be reverted if there was a failure.

          Show
          Basil James Whitehouse III added a comment - Oddly this issue doesn't happen when running a dry run of release:perform (e.g. mvn release:perform -DdryRun=true). This makes it awkward to verify fixes since a real release:prepare has to be performed and that will modify your poms which have to be reverted if there was a failure.
          Hide
          Basil James Whitehouse III added a comment -

          Actually I think this problem runs deeper than just test-jar classifiers. Other classifiers are broken as well. I've tried this with a project where there's an EJB client jar (with a classifier of 'client') and that doesn't work. Using a type of ejb-client fixed this as well. I'm guessing that any dependency with a classifier is probably broken.

          FYI: the ejb-client issue seems to be different from MRELEASE-129.

          Show
          Basil James Whitehouse III added a comment - Actually I think this problem runs deeper than just test-jar classifiers. Other classifiers are broken as well. I've tried this with a project where there's an EJB client jar (with a classifier of 'client') and that doesn't work. Using a type of ejb-client fixed this as well. I'm guessing that any dependency with a classifier is probably broken. FYI: the ejb-client issue seems to be different from MRELEASE-129 .
          Arnaud Heritier made changes -
          Component/s prepare [ 13615 ]
          Hide
          Florian Müller added a comment -

          I've found an another workaround.
          You could add a <optional>true</optional> to your dependency, like this:
          <dependency>
          <groupId>ch.swisscompagny.project</groupId>
          <artifactId>web</artifactId>
          <version>$

          {project.parent.version}

          </version>
          <classifier>classes</classifier>
          <optional>true</optional>
          </dependency>

          It's very useful with the maven-war-plugin and the overlay feature.

          Show
          Florian Müller added a comment - I've found an another workaround. You could add a <optional>true</optional> to your dependency, like this: <dependency> <groupId>ch.swisscompagny.project</groupId> <artifactId>web</artifactId> <version>$ {project.parent.version} </version> <classifier>classes</classifier> <optional>true</optional> </dependency> It's very useful with the maven-war-plugin and the overlay feature.
          Brett Porter made changes -
          Fix Version/s 2.1 [ 12571 ]
          Hide
          Israel E. Bethencourt added a comment -

          Maybe this bug is related to the same issue:

          http://jira.codehaus.org/browse/MRELEASE-567

          But seems nothing is moving about this.

          Show
          Israel E. Bethencourt added a comment - Maybe this bug is related to the same issue: http://jira.codehaus.org/browse/MRELEASE-567 But seems nothing is moving about this.
          Hide
          Israel E. Bethencourt added a comment -

          A workarround could be to change the preparationgoals in the release plugin configuration:

          <preparationGoals>clean install verify</preparationGoals>

          Show
          Israel E. Bethencourt added a comment - A workarround could be to change the preparationgoals in the release plugin configuration: <preparationGoals>clean install verify</preparationGoals>

            People

            • Assignee:
              Unassigned
              Reporter:
              Rod Coffin
            • Votes:
              15 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated: