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

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