[
http://jira.codehaus.org/browse/MDEP-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231934#action_231934
]
John Daniel edited comment on MDEP-259 at 8/13/10 4:02 PM:
-----------------------------------------------------------
I have also seen this issue manifest itself when trying to import an Existing
Maven Project in to the Eclipse workspace using M2Eclipse 0.10.2 where the pom
of the project that is being imported has a execution of
maven-dependency-plugin:copy-dependencies at phase process-resources.
(M2Eclipse has been configured with goal of process-resources on project
import).
The execution of the goal works as expected when executed from command line
(using Maven 2.2.1 and 3.0-beta-2), but when the goal is executed in Eclipse
(and M2Eclipse), it fails execution at the first dependency that is resolved
within the workspace.
The real break point is in the class CopyDependenciesMojo copyArtifact(
Artifact artifact, boolean removeVersion ) method. Specifically, the copyFile(
artifact.getFile(), destFile ) method fails. It fails because the destFileName
is not correct.
A few lines above that copyFile method call, the following code is executed:
String destFileName =
DependencyUtil.getFormattedFileName( artifact, removeVersion );
When artifact is resolved in M2Eclipse via workspace resolution, the artifact
is resolved to a project folder that ends in "target/classes". It does not
resolve to a file name like the other dependencies.
DependencyUtil.getFormattedFileName( artifact, removeVersion ) then executes.
If the "removeVersion" flag is false, then this method simply determines the
file name by the following means:
destFileName =
artifact.getFile().getName();
The File.getName() method looks like the following:
public String getName() {
int
index = path.lastIndexOf(separatorChar);
if
(index < prefixLength) return path.substring(prefixLength);
return
path.substring(index + 1);
}
So the filename is simply determined as "all characters to the right of the
last occurance of separatorChar." In the case of a M2Eclipse workspace
resolved project, this becomes "classes".
I agree with Andreas' proposed solution here. In the case of this specific use
case, it is probably best to retrieve the last built artifact verses trying to
copy a directory folder. You may not get the "latest and greatest" from your
active development project that is resolved in the Eclipse workspace, but you
would get at least some artifact to copy over from the local repository.
I tried Andreas' patch attached to this defect but it did not help in my case.
I do not know why it was not working in my case as he set it up.
What I did for a workaround was make a modification to the CopyDependenciesMojo
copyArtifact(Artifact, boolean) method. I added an "if" statement just before
the call to the copyFile( artifact.getFile(), destFile ) method. This "if"
statement simply looks to see if the artifact.getFile().getAbsolutePath() ends
with the artifact.getArtifactHandler().getExtension(). If it fails this test,
as this use case would, it simply logs a warning that the artifact is a
directory and bypasses the copyFile call. Here is the code excerpt:
// Only copy the file if it is
a real file and not a directory
if
(artifact.getFile().getAbsolutePath().endsWith(artifact.getArtifactHandler().getExtension()))
{
copyFile(
artifact.getFile(), destFile );
// Copy
POM if asked
if (
isCopyPom() )
{
This workaround may not be the correct approach as it assumes that there is no
use case where an artifact could fail this check and still be a file, but it
does serve my needs for now. The "if" statement may however be a possible
approach to identify when this siutation arises. I don't currently have the
time to implement the proposed solution that Andreas suggested ...but I might
tackle it in the future.
Anyway, I hope this helps.
Cheers!
John
was (Author: johnmdaniel):
I have also seen this issue manifest itself when trying to import an
Existing Maven Project in to the Eclipse workspace using M2Eclipse 0.10.2 where
the pom of the project that is being imported has a execution of
maven-dependency-plugin:copy-dependencies at phase process-resources.
(M2Eclipse has been configured with goal of process-resources on project
import).
The execution of the goal works as expected when executed from command line
(using Maven 2.2.1 and 3.0-beta-2), but when the goal is executed in Eclipse
(and M2Eclipse), it fails execution at the first dependency that is resolved
within the workspace.
The real break point is in the class CopyDependenciesMojo copyArtifact(
Artifact artifact, boolean removeVersion ) method. Specifically, the copyFile(
artifact.getFile(), destFile ) method fails. It fails because the destFileName
is not correct.
A few lines above that copyFile method call, the following code is executed:
String destFileName =
DependencyUtil.getFormattedFileName( artifact, removeVersion );
When artifact is resolved in M2Eclipse via workspace resolution, the artifact
is resolved to a project folder that ends in "target/classes". It does not
resolve to a file name like the other dependencies.
DependencyUtil.getFormattedFileName( artifact, removeVersion ) then executes.
If the "removeVersion" flag is false, then this method simply determines the
file name by the following means:
destFileName =
artifact.getFile().getName();
The File.getName() method looks like the following:
public String getName() {<br/>
int
index = path.lastIndexOf(separatorChar);<br/>
if
(index < prefixLength) return path.substring(prefixLength);<br/>
return
path.substring(index + 1);<br/>
}<br/>
So the filename is simply determined as "all characters to the right of the
last occurance of separatorChar." In the case of a M2Eclipse workspace
resolved project, this becomes "classes".
I agree with Andreas' proposed solution here. In the case of this specific use
case, it is probably best to retrieve the last built artifact verses trying to
copy a directory folder. You may not get the "latest and greatest" from your
active development project that is resolved in the Eclipse workspace, but you
would get at least some artifact to copy over from the local repository.
I tried Andreas' patch attached to this defect but it did not help in my case.
I do not know why it was not working in my case as he set it up.
What I did for a workaround was make a modification to the CopyDependenciesMojo
copyArtifact(Artifact, boolean) method. I added an "if" statement just before
the call to the copyFile( artifact.getFile(), destFile ) method. This "if"
statement simply looks to see if the artifact.getFile().getAbsolutePath() ends
with the artifact.getArtifactHandler().getExtension(). If it fails this test,
as this use case would, it simply logs a warning that the artifact is a
directory and bypasses the copyFile call. Here is the code excerpt:
// Only copy the file if it is
a real file and not a directory
if
(artifact.getFile().getAbsolutePath().endsWith(artifact.getArtifactHandler().getExtension()))
{
copyFile(
artifact.getFile(), destFile );
// Copy
POM if asked
if (
isCopyPom() )
{
This workaround may not be the correct approach as it assumes that there is no
use case where an artifact could fail this check and still be a file, but it
does serve my needs for now. The "if" statement may however be a possible
approach to identify when this siutation arises. I don't currently have the
time to implement the proposed solution that Andreas suggested ...but I might
tackle it in the future.
Anyway, I hope this helps.
Cheers!
John
> 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
