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

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

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development