Maven 2.x Dependency Plugin

dependency:copy fails when invoked from m2e with workspace resolution enabled, or more generally when copying within reactor for phases earlier than package

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.1
  • Fix Version/s: None
  • Component/s: copy, copy-dependencies
  • Labels:
    None
  • Number of attachments :
    3

Description

m2e resolves workspace artifacts to their output folders but dependency:copy expects all artifacts to be files. I will provide trivial patch shortly.

  1. File
    MDEP-187.diff
    12/Nov/08 4:27 PM
    0.9 kB
    Igor Fedorenko
  2. File
    MDEP-187b.diff
    13/Nov/08 12:15 PM
    6 kB
    Igor Fedorenko
  3. File
    MDEP-187c.diff
    23/Apr/12 6:38 AM
    2 kB
    Nicolás Cornaglia

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MNGECLIPSE-1027 [mng] Workspace dependency resolution doesn't work with maven-dependency-plugin

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MDEP-291 Error when copying within reactor for phases earlier than package

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MDEP-259 copy-dependencies fails with "Error copying artifact from .../target/classes to .../classes"

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MDEP-394 unpack behaves differently in multi-module build

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.
relates to

Bug - A problem which impairs or prevents the functions of the product. MASSEMBLY-411 Error on copy dependencies using Assembler Plugin (m2e Eclipse Plugin Workspace Resolution)

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MDEP-98 dependency:unpack: The source must not be a directory

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MDEP-194 ArchiverException when using maven dependency plugin in multi-module projects

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Igor Fedorenko added a comment -

updated path that fixes same exception in unpack mojo and also includes two unit tests.

Show
Igor Fedorenko added a comment - updated path that fixes same exception in unpack mojo and also includes two unit tests.
Hide
Permalink
Marcelo Alcantara added a comment -

I was having the same problem as mentioned on the MNGECLIPSE-1027 and saw the recomendation to update the maven-dependency-plugin to version 2.1.

I updated the plugin but still have the same problem.

Any ideas?

Show
Marcelo Alcantara added a comment - I was having the same problem as mentioned on the MNGECLIPSE-1027 and saw the recomendation to update the maven-dependency-plugin to version 2.1. I updated the plugin but still have the same problem. Any ideas?
Hide
Permalink
Felipe Desiderati added a comment -

I have the same problem too, and the only solution I´ve found was to simply disable workspace resolution. I know that is terrible and with this approach I have to install locally all the time the other dependent projects
Meanwhile, waiting for the fix.

Show
Felipe Desiderati added a comment - I have the same problem too, and the only solution I´ve found was to simply disable workspace resolution. I know that is terrible and with this approach I have to install locally all the time the other dependent projects Meanwhile, waiting for the fix.
Hide
Permalink
Julien Wajsberg added a comment -

Is it possible to have this patch applied if it works ?

Thanks.

Show
Julien Wajsberg added a comment - Is it possible to have this patch applied if it works ? Thanks.
Hide
Permalink
derek added a comment -

Is there any other workarounds for this one?
Thanks,
Derek

Show
derek added a comment - Is there any other workarounds for this one? Thanks, Derek
Hide
Permalink
Clint Shank added a comment -

My current workaround for this issue is to use the antrun plug-in. For example,

  <plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <executions>
      <execution>
        <!-- copy just built artifact to some lib dir -->
        <id>copy-to-lib</id>
        <goals>
          <goal>run</goal>
        </goals>
        <phase>package</phase>
        <configuration>
          <tasks>
            <copy
                file="${project.build.directory}/${project.build.finalName}.${project.packaging}"
                tofile="${some.lib.dir}/${project.artifactId}.${project.packaging}" />
          </tasks>
        </configuration>
      </execution>
    </executions>
  </plugin>

This allows "Resolve dependencies from Workspace projects" to work.

Show
Clint Shank added a comment - My current workaround for this issue is to use the antrun plug-in. For example, <plugin> <artifactId> maven-antrun-plugin </artifactId> <executions> <execution> <!-- copy just built artifact to some lib dir --> <id> copy-to-lib </id> <goals> <goal> run </goal> </goals> <phase> package </phase> <configuration> <tasks> <copy file= "${project.build.directory}/${project.build.finalName}.${project.packaging}" tofile= "${some.lib.dir}/${project.artifactId}.${project.packaging}" /> </tasks> </configuration> </execution> </executions> </plugin> This allows "Resolve dependencies from Workspace projects" to work.
Hide
Permalink
Nathan Wells added a comment -

It seems that there are many duplicates of this issue, or that the issue manifests itself in many different ways.

Show
Nathan Wells added a comment - It seems that there are many duplicates of this issue, or that the issue manifests itself in many different ways.
Hide
Permalink
Walt added a comment - - edited

I'm hitting this problem from the command line. 

            <plugin>
                <artifactId>maven-dependency-plugin</artifactId>
                <executions>
                    <execution>
                        <id>obtain instrumentation candidates</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>unpack</goal>
                        </goals>
                        <configuration>
                            <artifactItems>
                                <artifactItem>
                                    <groupId>${project.groupId}</groupId>
                                    <artifactId>my-control-plugins</artifactId>
                                </artifactItem>
                                <artifactItem>
                                    <groupId>${project.groupId}</groupId>
                                    <artifactId>my-control-plugins</artifactId>
                                    <classifier>sources</classifier>
                                    <includes>**/GeneratedPlugin.java</includes>
                                    <outputDirectory>${project.build.sourceDirectory}</outputDirectory>
                                </artifactItem>
                            </artifactItems>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

gives me


[ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.3:unpack (obtain instrumentation candidates) on project my-control-plugins-cobertura: Error unpacking file: /home/me/devel/my/execution/exec-plugins/my-control-plugins/target/classes to: /home/me/devel/execution/exec-plugins/my-control-plugins-cobertura/target/dependency
[ERROR] org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.3:unpack (obtain instrumentation candidates) on project oo-control-plugins-cobertura: Error unpacking file: /home/me/devel/execution/exec-plugins/my-control-plugins/target/classes to: /home/me/devel/execution/exec-plugins/my-control-plugins-cobertura/target/dependency
org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error unpacking file: /home/me/devel/execution/exec-plugins/my-control-plugins/target/classes to: /home/me/devel/execution/exec-plugins/my-control-plugins-cobertura/target/dependency
org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
	at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:267)
	at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:116)
	at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:94)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
	... 19 more
Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
	at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185)
	at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:118)
	at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:258)
	... 23 more

From the looks of it, this has been an issue now for 4 years and it's still not fixed?????

Show
Walt added a comment - - edited I'm hitting this problem from the command line. <plugin> <artifactId> maven-dependency-plugin </artifactId> <executions> <execution> <id> obtain instrumentation candidates </id> <phase> generate-sources </phase> <goals> <goal> unpack </goal> </goals> <configuration> <artifactItems> <artifactItem> <groupId> ${project.groupId} </groupId> <artifactId> my-control-plugins </artifactId> </artifactItem> <artifactItem> <groupId> ${project.groupId} </groupId> <artifactId> my-control-plugins </artifactId> <classifier> sources </classifier> <includes> **/GeneratedPlugin.java </includes> <outputDirectory> ${project.build.sourceDirectory} </outputDirectory> </artifactItem> </artifactItems> </configuration> </execution> </executions> </plugin> gives me [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.3:unpack (obtain instrumentation candidates) on project my-control-plugins-cobertura: Error unpacking file: /home/me/devel/my/execution/exec-plugins/my-control-plugins/target/classes to: /home/me/devel/execution/exec-plugins/my-control-plugins-cobertura/target/dependency [ERROR] org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.3:unpack (obtain instrumentation candidates) on project oo-control-plugins-cobertura: Error unpacking file: /home/me/devel/execution/exec-plugins/my-control-plugins/target/classes to: /home/me/devel/execution/exec-plugins/my-control-plugins-cobertura/target/dependency org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Error unpacking file: /home/me/devel/execution/exec-plugins/my-control-plugins/target/classes to: /home/me/devel/execution/exec-plugins/my-control-plugins-cobertura/target/dependency org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:267) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:116) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:94) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185) at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:118) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:258) ... 23 more From the looks of it, this has been an issue now for 4 years and it's still not fixed?????
Hide
Permalink
Nicolás Cornaglia added a comment -

My 2cents to this bug with m2e.
Added support to copy the expanded directory to expanded folders.

Show
Nicolás Cornaglia added a comment - My 2cents to this bug with m2e. Added support to copy the expanded directory to expanded folders.
Hide
Permalink
Art O Cathain added a comment -

Nicolas, I fiddled with your patch a bit (to add some debug logging) and added integration tests. I attached the result to MDEP-194. Can you take a look?

Show
Art O Cathain added a comment - Nicolas, I fiddled with your patch a bit (to add some debug logging) and added integration tests. I attached the result to MDEP-194 . Can you take a look?
Hide
Permalink
Herve Boutemy added a comment - - edited

copy problem looks a lot like unpack problem, but has a major difference: when unpack finds a directory, copying it ressembles a lot to unpacking packaged artifact (if no classifier and nothing generated during packaging)

but if copy finds a directory, what is it expected to do? copy the directory (even if expected result is a file)? create a zip file with the directory content? create a jar file (what to do with the Manifest?)? fail? ignore with warning?

this seems like there is no solution other than require to package first, or we'll get an approximation that can be more problematic than a clear failure

Show
Herve Boutemy added a comment - - edited copy problem looks a lot like unpack problem, but has a major difference: when unpack finds a directory, copying it ressembles a lot to unpacking packaged artifact (if no classifier and nothing generated during packaging) but if copy finds a directory, what is it expected to do? copy the directory (even if expected result is a file)? create a zip file with the directory content? create a jar file (what to do with the Manifest?)? fail? ignore with warning? this seems like there is no solution other than require to package first, or we'll get an approximation that can be more problematic than a clear failure
Hide
Permalink
Herve Boutemy added a comment - - edited

error message improved in r1368246
this doesn't fix the problem (which cannot be fixed IMHO) but at least makes it easier to track

notice that another corner case to take care is when the dependency to copy has a classifier: we can't even imagine the content before the artifact has been packaged

Show
Herve Boutemy added a comment - - edited error message improved in r1368246 this doesn't fix the problem (which cannot be fixed IMHO) but at least makes it easier to track notice that another corner case to take care is when the dependency to copy has a classifier: we can't even imagine the content before the artifact has been packaged
Hide
Permalink
Eric Pabst added a comment -

This problem happens when running phases before package (e.g. "compile", "test-compile", "process-classes"). A simple work-around that is often possible is to move the dependency:copy to a later phase such as prepare-package, which would rarely if ever be invoked directly, but instead be part of running "mvn package" (or a later phase).

Show
Eric Pabst added a comment - This problem happens when running phases before package (e.g. "compile", "test-compile", "process-classes"). A simple work-around that is often possible is to move the dependency:copy to a later phase such as prepare-package, which would rarely if ever be invoked directly, but instead be part of running "mvn package" (or a later phase).

People

  • Assignee:
    Unassigned
    Reporter:
    Igor Fedorenko
Vote (52)
Watch (37)

Dates

  • Created:
    Updated: