[jira] Closed: (MDEP-259) copy-dependencies fails with Error copying artifact from .../target/classes to .../classes
[
https://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen closed MDEP-259.
Resolution: Won't Fix
I had another look at the issue and it turns out that my proposed change no
longer works on Maven 3 because of some subtle changes in the behavior of
ArtifactResolver. I don't see any other way to get around this.
In my particular case (importing a complex multi-module build into Eclipse) I
now recommend users to do this with mvn -DskipTests=true install
eclipse:eclipse instead of mvn generate-test-resources eclipse:eclipse. The
drawback is that it increases the risk of getting into a chicken-and-egg
problem where one wants to refresh the Eclipse project to investigate a build
failure but it is not possible to do that because that build failure causes the
Maven command used to import the sources into Eclipse to fail...
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:
[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).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-259) copy-dependencies fails with Error copying artifact from .../target/classes to .../classes
[
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MDEP-259.
--
Resolution: Won't Fix
This is a problem with Maven Core, not the dependency plugin. It will only
happen if you are doing just mvn compile or maybe mvn test on the multimodule
build, because those modules haven't been packaged yet. When this happens, the
core hands the plugin a reference to the classes folder, but we expect a jar.
Instead of running mvn compile/test just always use mvn install and you'll be
fine. Alternatively, bind the dependency plugin to the package phase and it
won't run unless you do at least mvn package in which case all of the modules
will be jar'd already.
The _only_ workaround we could do in the plugin is to cause the dependency
plugin to detect that it has a folder and either:
1) ignore this dependency
2) go and attempt to create a jar from the classes
Neither of these is a correct fix because in 1, the resulting folder/archive
would be incomplete and 2 we have no way of reliably constructing the jar
exactly as it would be done in its own pom.
copy-dependencies fails with Error copying artifact from .../target/classes
to .../classes
Key: MDEP-259
URL: http://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:
[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).
--
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
