maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl M. Davis (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MNG-2877) unable to resolve attached artifacts from reactor that are not in repo. (patch applied in svn and IT tests added)
Date Fri, 02 Jul 2010 18:15:32 GMT

    [ http://jira.codehaus.org/browse/MNG-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=227063#action_227063
] 

Karl M. Davis commented on MNG-2877:
------------------------------------

The problem still seems to exist when running release:prepare in a multi-module project where
one of the modules uses dependency:copy-dependencies for a secondary artifact of one of the
other modules.

For example:
* {{parent-proj}} (running {{release:prepare}} or {{verify}} here will fail)
** {{child-a}}
*** produces a "primary" JAR artifact
*** also produces a "secondary" assembly artifact attached to the build, e.g. a {{.zip}} of
PDF documentation
** {{child-b}}
*** uses {{dependency:unpack-dependencies}} to get the "secondary" assembly from {{child-a}}

The {{release:prepare}} operation ends up failing when the {{unpack-dependencies}} goal can't
find the secondary artifact of {{child-a}} in the repository (hasn't been installed yet) or
in the reactor (this is the bug, I think). It fails with the following error:
{{Embedded error: Unable to download the artifact from any repository}}

I would recommend that this bug be re-opened. I am running Maven 2.2.1, using {{maven-release-plugin:2.0}},
and {{maven-dependency-plugin:2.1}}.

> unable to resolve attached artifacts from reactor that are not in repo. (patch applied
in svn and IT tests added)
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-2877
>                 URL: http://jira.codehaus.org/browse/MNG-2877
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Artifacts and Repositories
>    Affects Versions: 2.0.2, 2.0.3, 2.0.4, 2.0.5
>            Reporter: Brian Fox
>            Assignee: Jason van Zyl
>             Fix For: 2.0.6
>
>         Attachments: test-bug-maven-release.zip
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message