[
https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MDEP-259:
-------------------------------
Description:
Scenario:
* dependency:copy-dependencies is used to copy a dependency artifact that is
part of the same multi-module build.
* The compile phase is executed, but not the package phase.
An example of this scenario is using maven-eclipse-plugin to import a Maven
project with generated test (re)sources. In this case, one would execute "mvn
generate-test-resources eclipse:eclipse" to make sure that the generated
(re)sources are imported into the workspace (by default, maven-eclipse-plugin
executes generate-sources and generate-resources, but not generate-test-sources
and generate-test-resources).
Result: The build fails with the following error:
{noformat}[INFO] [dependency:copy-dependencies {execution: default}]
[INFO] Copying classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error copying artifact from
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
Embedded error:
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No such
file or directory){noformat}
Steps to reproduce:
* Unpack the attached test project and build the entire project once with "mvn
install".
* Execute "mvn generate-resources" from the root project -> success (because
the compile phase is not executed)
* Execute "mvn package" from the root project -> success (because the package
phase is executed)
* Execute "mvn generate-test-resources" from the root project -> fails (because
the compile phase is executed, but not the package phase)
* Execute "mvn generate-test-resources" in project2 -> success (because the
dependency is not part of the same build)
Root cause analysis: In the scenario described above (compile phase executed,
package phase not executed), Artifact#getFile() points to the target/classes
directory instead of the output artifact. dependency:copy-dependencies doesn't
detect this situation and blindly attempts to execute the copy operation. This
fails with the error message shown above. Note that even if the operation
didn't fail, it would produce an unexpected result.
Proposed fix (see attached patch): Change maven-dependency-plugin to detect
this situation and let it replace the original Artifact object by a new one
resolved from the repository (which would then refer to the artifact generated
by a previous build, exactly as in the mvn generate-resources case).
was:
Scenario:
* dependency:copy-dependencies is used to copy a dependency artifact that is
part of the same multi-module build.
* The compile phase is executed, but not the package phase.
An example of this scenario is using maven-eclipse-plugin to import a Maven
project with generated test (re)sources. In this case, one would execute "mvn
generate-test-resources eclipse:eclipse" to make sure that the generated
(re)sources are imported into the workspace (by default, maven-eclipse-plugin
executes generate-sources and generate-resources, but not generate-test-sources
and generate-test-resources).
Result: The build fails with the following error:
[INFO] [dependency:copy-dependencies {execution: default}]
[INFO] Copying classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error copying artifact from
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
/Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
Embedded error:
/Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No such
file or directory)
Steps to reproduce:
* Unpack the attached test project and build the entire project once with "mvn
install".
* Execute "mvn generate-resources" from the root project -> success (because
the compile phase is not executed)
* Execute "mvn package" from the root project -> success (because the package
phase is executed)
* Execute "mvn generate-test-resources" from the root project -> fails (because
the compile phase is executed, but not the package phase)
* Execute "mvn generate-test-resources" in project2 -> success (because the
dependency is not part of the same build)
Root cause analysis: In the scenario described above (compile phase executed,
package phase not executed), Artifact#getFile() points to the target/classes
directory instead of the output artifact. dependency:copy-dependencies doesn't
detect this situation and blindly attempts to execute the copy operation. This
fails with the error message shown above. Note that even if the operation
didn't fail, it would produce an unexpected result.
Proposed fix (see attached patch): Change maven-dependency-plugin to detect
this situation and let it replace the original Artifact object by a new one
resolved from the repository (which would then refer to the artifact generated
by a previous build, exactly as in the mvn generate-resources case).
> copy-dependencies fails with "Error copying artifact from .../target/classes
> to .../classes"
> --------------------------------------------------------------------------------------------
>
> Key: MDEP-259
> URL: https://jira.codehaus.org/browse/MDEP-259
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy-dependencies
> Affects Versions: 2.0, 2.1
> Environment: Maven 2.0.9
> maven-dependency-plugin 2.0, 2.1 or 2.2-SNAPSHOT (r922616)
> Reporter: Andreas Veithen
> Assignee: Brian Fox
> Attachments: patch.txt, test-project.zip
>
>
> Scenario:
> * dependency:copy-dependencies is used to copy a dependency artifact that is
> part of the same multi-module build.
> * The compile phase is executed, but not the package phase.
> An example of this scenario is using maven-eclipse-plugin to import a Maven
> project with generated test (re)sources. In this case, one would execute "mvn
> generate-test-resources eclipse:eclipse" to make sure that the generated
> (re)sources are imported into the workspace (by default, maven-eclipse-plugin
> executes generate-sources and generate-resources, but not
> generate-test-sources and generate-test-resources).
> Result: The build fails with the following error:
> {noformat}[INFO] [dependency:copy-dependencies {execution: default}]
> [INFO] Copying classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error copying artifact from
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes to
> /Users/veithen/dev/maven/axis/axis2/modules/fastinfoset/target/repo/modules/classes
> Embedded error:
> /Users/veithen/dev/maven/axis/axis2/modules/addressing/target/classes (No
> such file or directory){noformat}
> Steps to reproduce:
> * Unpack the attached test project and build the entire project once with
> "mvn install".
> * Execute "mvn generate-resources" from the root project -> success (because
> the compile phase is not executed)
> * Execute "mvn package" from the root project -> success (because the package
> phase is executed)
> * Execute "mvn generate-test-resources" from the root project -> fails
> (because the compile phase is executed, but not the package phase)
> * Execute "mvn generate-test-resources" in project2 -> success (because the
> dependency is not part of the same build)
> Root cause analysis: In the scenario described above (compile phase executed,
> package phase not executed), Artifact#getFile() points to the target/classes
> directory instead of the output artifact. dependency:copy-dependencies
> doesn't detect this situation and blindly attempts to execute the copy
> operation. This fails with the error message shown above. Note that even if
> the operation didn't fail, it would produce an unexpected result.
> Proposed fix (see attached patch): Change maven-dependency-plugin to detect
> this situation and let it replace the original Artifact object by a new one
> resolved from the repository (which would then refer to the artifact
> generated by a previous build, exactly as in the mvn generate-resources case).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
