Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2, 2.0.3, 2.0.4, 2.0.5
-
Fix Version/s: 2.0.6
-
Component/s: Artifacts and Repositories
-
Labels:None
-
Complexity:Intermediate
-
Testcase included:yes
-
Number of attachments :
Description
The patch has been applied here: https://svn.apache.org/repos/asf/maven/components/branches/maven-project-mdep64
and the IT tests are already added to core-it but commented out from the suite. To enable it, uncomment this line: //suite.addTestSuite( MavenIT0118AttachedArtifactsInReactor.class );
-----------------------
This is from MDEP-64:
We have a project with a few sub-projects. Only one of those subprojects uses the maven-dependency-plugin, copying the jar file artifact from one of the sibling sub-projects. The dependency plugin has worked fine in another multi-project m2 buld and release when the dependency copy was only referencing projects outside the multi-project's project tree.
But in the present multi-project release, copying that sibling jar file with the dependency plugin causes the mvn release:prepare step to fail, because it can't find the released version in the release repository. It doesn't care about referencing sibling project dependencies from the regular pom dependencies, it only chokes for the dependency:copy.
Here's a diagram for the issue with three pseudo-poms. I omitted groupId's, scm, distributionManagement, and other content from the poms that were not necessary to communicate the basic issue. I've worked around this by using the antrun plugin, which is unpleasant and untidy. This seems like it might be related to MDEP-44.
superproject/
A/ -> no dependencies
B/ -> dependency:copy A
//superproject/pom.xml (abbrieviated)
<project>
<artifactId>superproject</artifactId>
<packaging>pom</packaging>
<version>1.0.0.1-SNAPSHOT</version>
<modules>
<module>A</module>
<module>B</module>
</modules>
</project>
// superproject/A/pom.xml (abbrievated)
<project>
<parent>
<artifactId>superproject</artifactId>
<version>1.0.0.1-SNAPSHOT</version>
</parent>
<artifactId>A</artifactId>
<version>1.0.0.1-SNAPSHOT</version>
</project>
// superproject/B/pom.xml (abbreviated)
<project>
<parent>
<artifactId>superproject</artifactId>
<version>1.0.0.1-SNAPSHOT</version>
</parent>
<artifactId>B</artifactId>
<packaging>war</packaging>
<version>1.0.0.1-SNAPSHOT</version>
<build>
<finalName>FooWar</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy</id>
<goals>
<goal>copy</goal>
</goals>
<phase>package</phase>
<configuration>
<artifactItems>
<artifactItem>
<artifactId>A</artifactId>
<version>${pom.version}</version>
<type>jar</type>
</artifactItem>
</artifactItems>
<outputDirectory>${project.build.directory}/${pom.build.finalName}/jars</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<artifactId>A</artifactId>
<version>${pom.version}</version>
</dependency>
</dependencies>
</project>
The error message during mvn release:prepare is basically:
[INFO] Building B
[INFO] task-segment: [clean, integration-test]
[INFO] ----------------------------------------------------------------------------
[INFO] [clean:clean] <skip deleting directories>
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: <groupId>:A:null:1.0.0.1:jar
Downloading: <details>/1.0.0.1/A-1.0.0.1.jar
[WARNING] Unable to get resource from repository sizzle (<our repository details>)
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
GroupId: <groupId>
ArtifactId: A
Version: 1.0.0.1
Reason: Unable to download the artifact from any repository
Attachments
Issue Links
| This issue is duplicated by: | ||||
| MNG-2398 | attached artifacts (such as assemblies) are not resolved in the workspace when running 'package' phase |
|
|
|
| This issue relates to: | ||||
| MNG-2921 | ejb-client dependency no longer resolved in reactor build |
|
|
|
| MNG-2045 | Maven can't compile against sibling test-jar dependency in multiproject (Test Attached) |
|
|
|
| MNG-4248 | CLONE -Maven can't compile against sibling test-jar dependency in multiproject (Test Attached) |
|
|
|
| MNG-4233 | Artifact does not get resolved from the reactor |
|
|
|
| This issue is depended upon by: | ||||
| MDEP-44 | unpacking/copying of attached artifacts from reactor projects doesn't work |
|
|
|
| MDEP-64 | Subprojects using m2 dependency plugin causes release:prepare to fail |
|
|
|
| MNG-3076 | Dependency on test-jar is not resolved with 'package' target, must use 'install' |
|
|
|
Description from
MDEP-44: (this has the patch and tests I used)I have a parent project, which has two modules - "one" and "two".
"one" uses assembly:single to attach an assembly to its build.
"two" depends upon that assembly, and uses "dependency:unpack-dependencies" to unpack it.
This works fine if the projects are built separately - and the assembly is installed in the local repository. However, when using the reactor to build both projects at once, the dependency plugin still looks in the local repository for the assembly, rather than using the artifact which was just built. This either fails, or produces the wrong version of the assembly.
I suspect this may be a bug with the reactor mechanism - but I don't really understand how all that works...
The attachment demonstrates the problem.
MDEP-44: (this has the patch and tests I used) I have a parent project, which has two modules - "one" and "two". "one" uses assembly:single to attach an assembly to its build. "two" depends upon that assembly, and uses "dependency:unpack-dependencies" to unpack it. This works fine if the projects are built separately - and the assembly is installed in the local repository. However, when using the reactor to build both projects at once, the dependency plugin still looks in the local repository for the assembly, rather than using the artifact which was just built. This either fails, or produces the wrong version of the assembly. I suspect this may be a bug with the reactor mechanism - but I don't really understand how all that works... The attachment demonstrates the problem.