Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Auto Closed
    • 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"

      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".

      1. example.jar
        2 kB
        Rod Coffin

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          218d 9h 44m 1 Paul Gier 22/Apr/08 22:35
          Closed Closed Reopened Reopened
          30d 10h 43m 1 Paul Gier 23/May/08 09:19
          Reopened Reopened Closed Closed
          2662d 11h 25m 1 Michael Osipov 06/Sep/15 20:44
          Michael Osipov made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Auto Closed [ 10000 ]
          Hide
          Michael Osipov added a comment -

          This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.

          Show
          Michael Osipov added a comment - This issue has been auto closed because it has been inactive for a long period of time. If you think this issue still applies, retest your problem with the most recent version of Maven and the affected component, reopen and post your results.
          Mark Thomas made changes -
          Workflow jira [ 12962328 ] Default workflow, editable Closed status [ 13000272 ]
          Mark Thomas made changes -
          Project Import Mon Apr 06 00:52:26 UTC 2015 [ 1428281546237 ]
          Mark Thomas made changes -
          Workflow jira [ 12724108 ] Default workflow, editable Closed status [ 12763389 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 12:15:05 UTC 2015 [ 1428236105845 ]
          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>
          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.
          Brett Porter made changes -
          Fix Version/s 2.1 [ 12571 ]
          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.
          Arnaud HERITIER made changes -
          Component/s prepare [ 13615 ]
          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 .
          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 -

          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
          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
          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.
          Paul Gier made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          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 -
          Fix Version/s 2.0-beta-8 [ 13812 ]
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Fix Version/s 2.0 [ 12571 ]
          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 -
          Fix Version/s 2.0-beta-8 [ 13812 ]
          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.
          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.
          brianfox made changes -
          Link This issue depends upon MNG-2277 [ MNG-2277 ]
          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.
          Paul Gier made changes -
          Link This issue depends upon MJAR-75 [ MJAR-75 ]
          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 -
          Field Original Value New Value
          Link This issue depends upon MNG-2277 [ MNG-2277 ]
          Rod Coffin created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Rod Coffin
            • Votes:
              14 Vote for this issue
              Watchers:
              17 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development