Maven 2.x Release Plugin

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

depends upon

Bug - A problem which impairs or prevents the functions of the product. MJAR-75 [PATCH] Wrong artifact type attached to the project by the test-jar goal

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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.
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (15)
Watch (16)

Dates

  • Created:
    Updated: