Uploaded image for project: 'Maven Dependency Plugin'
  1. Maven Dependency Plugin
  2. MDEP-187

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
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.1
    • Fix Version/s: None
    • Component/s: copy, copy-dependencies
    • Labels:
      None

      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. MDEP-187.diff
        0.9 kB
        igorfie
      2. MDEP-187b.diff
        6 kB
        igorfie
      3. MDEP-187c.diff
        2 kB
        Nicolás Cornaglia

        Issue Links

          Activity

          Hide
          igorf Igor Fedorenko added a comment -

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

          Show
          igorf Igor Fedorenko added a comment - updated path that fixes same exception in unpack mojo and also includes two unit tests.
          Hide
          maralc 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
          maralc 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
          desiderati Felipe Desiderati e Souza 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
          desiderati Felipe Desiderati e Souza 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
          julienw Julien Wajsberg added a comment -

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

          Thanks.

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

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

          Show
          dokeeffe derek added a comment - Is there any other workarounds for this one? Thanks, Derek
          Hide
          clintshank 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
          clintshank 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
          nwwells@gmail.com 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
          nwwells@gmail.com 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
          hemna 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
          hemna 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
          ncornagl Nicolás Cornaglia added a comment -

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

          Show
          ncornagl Nicolás Cornaglia added a comment - My 2cents to this bug with m2e. Added support to copy the expanded directory to expanded folders.
          Hide
          artbristol 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
          artbristol 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
          hboutemy Hervé 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
          hboutemy Hervé 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
          hboutemy Hervé Boutemy added a comment - - edited

          error message improved in r1368246, for 2.5 release of the plugin
          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
          hboutemy Hervé Boutemy added a comment - - edited error message improved in r1368246 , for 2.5 release of the plugin 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
          epabst 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
          epabst 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).
          Hide
          arlol Arlo Louis O'Keeffe added a comment -

          I have added a copy to the pre-integration-phase which AFAIK should work since it's after packaging. I nonetheless get the warning. Is this expected?

          Show
          arlol Arlo Louis O'Keeffe added a comment - I have added a copy to the pre-integration-phase which AFAIK should work since it's after packaging. I nonetheless get the warning. Is this expected?
          Hide
          hboutemy Hervé Boutemy added a comment -

          Ario: please open another Jira issue with sample pom to reproduce you issue

          Show
          hboutemy Hervé Boutemy added a comment - Ario: please open another Jira issue with sample pom to reproduce you issue
          Hide
          ntshko Hannes Kogler added a comment -

          same problem here!

          we have a common parent project that hosts some ant scripts we use in the single child projects
          what we want to do is to:
          => download the zip file of the parent project, including all the common ant scripts we need, and unpack it to the target folder of every single child project.

          on the build server, where pure Maven is used, this is no problem. But if we are in Eclipse workspace where we use m2e, and the workspace resolution is enabled, AND the parent project is also checked out in the same workspace directory, the download of the zip dependency doesn't work. The downloaded zip file gets corrupted and we get the message:
          Error unpacking file: ... org.codehaus.plexus.archiver.ArchiverException: Error while expanding => the downloaded artifact is NOT the zip, but just the corresponding pom.xml file! (named as zip archive)

          As a workaround we tried to implement the same download concept using the maven-assembly-plugin, but this results in the same error trying to unpack the invalid archive. So I would say this is more a m2e bug than a specific problem in the maven-dependency-plugin?!

          Show
          ntshko Hannes Kogler added a comment - same problem here! we have a common parent project that hosts some ant scripts we use in the single child projects what we want to do is to: => download the zip file of the parent project, including all the common ant scripts we need, and unpack it to the target folder of every single child project. on the build server, where pure Maven is used, this is no problem. But if we are in Eclipse workspace where we use m2e, and the workspace resolution is enabled , AND the parent project is also checked out in the same workspace directory, the download of the zip dependency doesn't work. The downloaded zip file gets corrupted and we get the message: Error unpacking file: ... org.codehaus.plexus.archiver.ArchiverException: Error while expanding => the downloaded artifact is NOT the zip, but just the corresponding pom.xml file! (named as zip archive) As a workaround we tried to implement the same download concept using the maven-assembly-plugin, but this results in the same error trying to unpack the invalid archive. So I would say this is more a m2e bug than a specific problem in the maven-dependency-plugin?!
          Hide
          wgoldman Warren Goldman added a comment -

          I am having this problem also. It seems to come and go, however, sometimes the error is there sometimes it is not. I can't predict it.

          Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187.
          (org.apache.maven.plugins:maven-dependency-plugin:2.8:copy:unpack-balance-app:generate-sources)

          Show
          wgoldman Warren Goldman added a comment - I am having this problem also. It seems to come and go, however, sometimes the error is there sometimes it is not. I can't predict it. Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187 . (org.apache.maven.plugins:maven-dependency-plugin:2.8:copy:unpack-balance-app:generate-sources)
          Hide
          ntshko Hannes Kogler added a comment -

          @Warren
          but I need to download my artifact in a phase before package. the phase I want to use this is initialize.
          and Maven itself does it without any problems, but only when using the m2e plugin ("Maven update project" in Eclipse instead of "run as Maven install") the error that the downloaded artifact is invalid occurs

          Show
          ntshko Hannes Kogler added a comment - @Warren but I need to download my artifact in a phase before package. the phase I want to use this is initialize. and Maven itself does it without any problems, but only when using the m2e plugin ("Maven update project" in Eclipse instead of "run as Maven install") the error that the downloaded artifact is invalid occurs
          Hide
          ntshko Hannes Kogler added a comment -

          Perhaps the logging gives some important hints for fixing this bad issue...
          [*m2e plugin version*: 1.6.0.20140823-1318; using standalone Maven version 3.2.3]
          [*eclipse version*: Luna Service Release 1 (4.4.1); Build id 20140925-1800]

          if the workspace resolution is deactivated, the copying works and the message in the Maven console says:

          11/17/14, 12:57:32 PM GMT+1: [INFO] Copying some.project-XX.XX.XX.jar to C:\workspaces\some.other\target\some.project.jar

          if the workspace resolution is ACTIVE, m2e starts any other process on the maven-dependency-plugin and fails copying with the message in the Maven console:

          11/17/14, 1:15:02 PM GMT+1: [INFO] Copying classes to C:\workspaces\some.other\target\some.project.jar

          *After all when failing he tries to copy only the classes of the jar file??!! *

          Show
          ntshko Hannes Kogler added a comment - Perhaps the logging gives some important hints for fixing this bad issue... [*m2e plugin version*: 1.6.0.20140823-1318; using standalone Maven version 3.2.3] [*eclipse version*: Luna Service Release 1 (4.4.1); Build id 20140925-1800] if the workspace resolution is deactivated, the copying works and the message in the Maven console says: 11/17/14, 12:57:32 PM GMT+1: [INFO] Copying some.project-XX.XX.XX.jar to C:\workspaces\some.other\target\some.project.jar if the workspace resolution is ACTIVE, m2e starts any other process on the maven-dependency-plugin and fails copying with the message in the Maven console: 11/17/14, 1:15:02 PM GMT+1: [INFO] Copying classes to C:\workspaces\some.other\target\some.project.jar *After all when failing he tries to copy only the classes of the jar file??!! *
          Hide
          tknerr Torben Knerr added a comment -

          Also having this issue. Updating maven-dependency-plugin to >= 2.5 gives me the improved error message, however I do not get rid of the warning.

          No matter which phase I'm using, it will be always there after doing "Maven -> Update Project..."

          @Warren: the error disappears after a "mvn clean", but it comes back right after "Maven -> Update Project..."...

          Show
          tknerr Torben Knerr added a comment - Also having this issue. Updating maven-dependency-plugin to >= 2.5 gives me the improved error message, however I do not get rid of the warning. No matter which phase I'm using, it will be always there after doing "Maven -> Update Project..." @Warren: the error disappears after a "mvn clean", but it comes back right after "Maven -> Update Project..."...
          Hide
          sfalk Stefan Falk added a comment - - edited

          And here is another one who has this issue. This issue has been created on 12/Nov/08 and nobody is assigned to it. So is there a realistic chance that this gets fixed?

          I have tried to change the phase but it didn't help.

          pom.xml
          		<plugins>
          			<plugin>
          				<artifactId>maven-dependency-plugin</artifactId>
          				<executions>
          					<execution>
          						<phase>package</phase>
          						<!-- up to <phase>deploy</phase> -->
          						<goals>
          							<goal>copy-dependencies</goal>
          						</goals>
          						<configuration>
          							<outputDirectory>${project.basedir}/war/WEB-INF/lib</outputDirectory>
          						</configuration>
          					</execution>
          				</executions>
          			</plugin>
          		</plugins>
          

          Error Message:
          Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187.

          Show
          sfalk Stefan Falk added a comment - - edited And here is another one who has this issue. This issue has been created on 12/Nov/08 and nobody is assigned to it. So is there a realistic chance that this gets fixed? I have tried to change the phase but it didn't help. pom.xml <plugins> <plugin> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <phase> package </phase> <!-- up to <phase>deploy</phase> --> <goals> <goal>copy-dependencies</goal> </goals> <configuration> <outputDirectory>${project.basedir}/war/WEB-INF/lib</outputDirectory> </configuration> </execution> </executions> </plugin> </plugins> Error Message: Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187 .
          Hide
          jhalterman Jonathan Halterman added a comment -

          Are there any realistic workarounds to this? As Stefan Falk said, changing the phase doesn't help.

          Show
          jhalterman Jonathan Halterman added a comment - Are there any realistic workarounds to this? As Stefan Falk said, changing the phase doesn't help.
          Hide
          ntshko Hannes Kogler added a comment -

          I don't know the implementation of the m2e Maven integration plugin for Eclipse, but since the maven-dependency-plugin perfectly works in maven standalone builds (from command line), the question is if the problem is not located in the maven plugin itself, but in the combination of the maven-dependency-plugin with the m2e world in Eclipse.

          Therefore perhaps the best solution would be to check if modifying the m2e connector plugin for the maven-dependency-plugin (https://github.com/ianbrandt/m2e-maven-dependency-plugin) would help here anyhow?!

          Show
          ntshko Hannes Kogler added a comment - I don't know the implementation of the m2e Maven integration plugin for Eclipse, but since the maven-dependency-plugin perfectly works in maven standalone builds (from command line), the question is if the problem is not located in the maven plugin itself, but in the combination of the maven-dependency-plugin with the m2e world in Eclipse. Therefore perhaps the best solution would be to check if modifying the m2e connector plugin for the maven-dependency-plugin ( https://github.com/ianbrandt/m2e-maven-dependency-plugin ) would help here anyhow?!
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user CMoH opened a pull request:

          https://github.com/apache/incubator-brooklyn/pull/755

          Rename org apache

          Rename more packages to add the org.apache prefix.

          I have run mvn clean install (which runs the unit tests). For some reason running mvn test alone fails with the following error:

          [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project brooklyn-software-base: Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187. -> [Help 1]

          Maybe some dependencies were missed?

          Please review.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/CMoH/incubator-brooklyn rename_org_apache

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/incubator-brooklyn/pull/755.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #755


          commit a1613a60401ddaa8e7e5cd84c339f378e94ccab6
          Author: Ciprian Ciubotariu <cheepeero@gmx.net>
          Date: 2015-07-16T08:27:15Z

          brooklyn-rest-client: add org.apache package prefix

          commit 40b2ba875f86288b82a29d94755f0594e4608d56
          Author: Ciprian Ciubotariu <cheepeero@gmx.net>
          Date: 2015-07-16T12:48:59Z

          brooklyn-jsgui: add org.apache package prefix

          commit 743e8597de18ab07390e83b4dfc993c0a84a8f44
          Author: Ciprian Ciubotariu <cheepeero@gmx.net>
          Date: 2015-07-16T15:10:16Z

          brooklyn-dist: add org.apache package prefix

          commit 4959bb430682bc2176afdda74879a59ef4b66098
          Author: Ciprian Ciubotariu <cheepeero@gmx.net>
          Date: 2015-07-16T15:35:57Z

          brooklyn-cli: add org.apache package prefix

          Also update dependent scripts/classes in brooklyn-archetype-quickstart,
          brooklyn-example-simple-nosql-cluster and brooklyn-dist.

          commit 73eef446a7b04e174508271423856cd5c0a6f864
          Author: Ciprian Ciubotariu <cheepeero@gmx.net>
          Date: 2015-07-16T16:11:03Z

          brooklyn-launcher: add org.apache package prefix

          Also update dependent projects.

          commit 1c83d3824c18a89a249d18ee057080994829dc54
          Author: Ciprian Ciubotariu <cheepeero@gmx.net>
          Date: 2015-07-17T09:18:47Z

          brooklyn-storage-hazelcast: add org.apache package prefix


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user CMoH opened a pull request: https://github.com/apache/incubator-brooklyn/pull/755 Rename org apache Rename more packages to add the org.apache prefix. I have run mvn clean install (which runs the unit tests). For some reason running mvn test alone fails with the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project brooklyn-software-base: Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187 . -> [Help 1] Maybe some dependencies were missed? Please review. You can merge this pull request into a Git repository by running: $ git pull https://github.com/CMoH/incubator-brooklyn rename_org_apache Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-brooklyn/pull/755.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #755 commit a1613a60401ddaa8e7e5cd84c339f378e94ccab6 Author: Ciprian Ciubotariu <cheepeero@gmx.net> Date: 2015-07-16T08:27:15Z brooklyn-rest-client: add org.apache package prefix commit 40b2ba875f86288b82a29d94755f0594e4608d56 Author: Ciprian Ciubotariu <cheepeero@gmx.net> Date: 2015-07-16T12:48:59Z brooklyn-jsgui: add org.apache package prefix commit 743e8597de18ab07390e83b4dfc993c0a84a8f44 Author: Ciprian Ciubotariu <cheepeero@gmx.net> Date: 2015-07-16T15:10:16Z brooklyn-dist: add org.apache package prefix commit 4959bb430682bc2176afdda74879a59ef4b66098 Author: Ciprian Ciubotariu <cheepeero@gmx.net> Date: 2015-07-16T15:35:57Z brooklyn-cli: add org.apache package prefix Also update dependent scripts/classes in brooklyn-archetype-quickstart, brooklyn-example-simple-nosql-cluster and brooklyn-dist. commit 73eef446a7b04e174508271423856cd5c0a6f864 Author: Ciprian Ciubotariu <cheepeero@gmx.net> Date: 2015-07-16T16:11:03Z brooklyn-launcher: add org.apache package prefix Also update dependent projects. commit 1c83d3824c18a89a249d18ee057080994829dc54 Author: Ciprian Ciubotariu <cheepeero@gmx.net> Date: 2015-07-17T09:18:47Z brooklyn-storage-hazelcast: add org.apache package prefix
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user asfgit closed the pull request at:

          https://github.com/apache/incubator-brooklyn/pull/755

          Show
          githubbot ASF GitHub Bot added a comment - Github user asfgit closed the pull request at: https://github.com/apache/incubator-brooklyn/pull/755
          Hide
          ftorres F. Torres added a comment -

          I'm also getting some "errors" with this jira message, but after adding the below to the parent pom it seems to be ok

          <!-- Code to make eclipse happy -->
          <plugin>
          	<groupId>org.eclipse.m2e</groupId>
          	<artifactId>lifecycle-mapping</artifactId>
          	<version>1.0.0</version>
          	<configuration>
          		<lifecycleMappingMetadata>
          			<pluginExecutions>
          				<pluginExecution>
          					<pluginExecutionFilter>
          						<groupId>org.apache.maven.plugins</groupId>
          						<artifactId>maven-dependency-plugin</artifactId>
          						<versionRange>[1.0.0,)</versionRange>
          						<goals>
          							<goal>copy-dependencies</goal>
          						</goals>
          					</pluginExecutionFilter>
          					<action>
          						<ignore />
          					</action>
          				</pluginExecution>
          			</pluginExecutions>
          		</lifecycleMappingMetadata>
          	</configuration>
          </plugin>
          
          Show
          ftorres F. Torres added a comment - I'm also getting some "errors" with this jira message, but after adding the below to the parent pom it seems to be ok <!-- Code to make eclipse happy --> <plugin> <groupId> org.eclipse.m2e </groupId> <artifactId> lifecycle-mapping </artifactId> <version> 1.0.0 </version> <configuration> <lifecycleMappingMetadata> <pluginExecutions> <pluginExecution> <pluginExecutionFilter> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-dependency-plugin </artifactId> <versionRange> [1.0.0,) </versionRange> <goals> <goal> copy-dependencies </goal> </goals> </pluginExecutionFilter> <action> <ignore /> </action> </pluginExecution> </pluginExecutions> </lifecycleMappingMetadata> </configuration> </plugin>
          Hide
          hohwille Jörg Hohwiller added a comment -

          I am getting this error on the commandline when building the site. Actually in my case a profile is triggered by maven where I can not see any reason why it should be activated.

          <activation>
            <file>
              <exists>${basedir}/src/main/deb/app</exists>
            </file>
          </activation
          

          The file is not there. It seems there is a bug in maven itself that when the site is build and build of modules is forked then there are some side effects between the modules:

          [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
          [INFO] Forking foo-app x.y.z-SNAPSHOT
          [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

          MDEP can of course do pretty much nothing about general bugs in maven but you should revisit your error reporting that can be missleading:

          [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project foo: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.10:copy (profile-deps) on project foo-app: Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187. -> [Help 1]

          BTW: You should update the Description of this issue. Open since 2008 and trivial patch will be applied shortly might also be misleading...

          Show
          hohwille Jörg Hohwiller added a comment - I am getting this error on the commandline when building the site. Actually in my case a profile is triggered by maven where I can not see any reason why it should be activated. <activation> <file> <exists>${basedir}/src/main/deb/app</exists> </file> </activation The file is not there. It seems there is a bug in maven itself that when the site is build and build of modules is forked then there are some side effects between the modules: [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [INFO] Forking foo-app x.y.z-SNAPSHOT [INFO] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> MDEP can of course do pretty much nothing about general bugs in maven but you should revisit your error reporting that can be missleading: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project foo: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.10:copy (profile-deps) on project foo-app: Artifact has not been packaged yet. When used on reactor artifact, copy should be executed after packaging: see MDEP-187 . -> [Help 1] BTW: You should update the Description of this issue. Open since 2008 and trivial patch will be applied shortly might also be misleading...
          Hide
          toniocus Tonio Caputo added a comment -

          This is definitely NOT a m2e problem but a maven-dependency-plugin problem, I'm having the same problem just in CLI interface with a reactor Assembly pom.

          Sometimes it works sometimes it not, not able to find how to make it work, but I have 2 very similar projects
          in one it works, in the other it does not, and always running in CLI, with the same version of plugin.

          Cannot post them here, because there are really big projects, but I'll try to reduce them to the minimum expression
          and see if I can find the differences, hope its possible.

          Show
          toniocus Tonio Caputo added a comment - This is definitely NOT a m2e problem but a maven-dependency-plugin problem, I'm having the same problem just in CLI interface with a reactor Assembly pom. Sometimes it works sometimes it not, not able to find how to make it work, but I have 2 very similar projects in one it works, in the other it does not, and always running in CLI, with the same version of plugin. Cannot post them here, because there are really big projects, but I'll try to reduce them to the minimum expression and see if I can find the differences, hope its possible.
          Hide
          toniocus Tonio Caputo added a comment - - edited

          Interest thing I found:

          If I use maven-jar-plugin version 2.5 or greater it FAILS

          If I use maven-jar-plugin version 2.4 it works OK

          May be the problem is not in maven-dependency-plugin ?

          Show
          toniocus Tonio Caputo added a comment - - edited Interest thing I found: If I use maven-jar-plugin version 2.5 or greater it FAILS If I use maven-jar-plugin version 2.4 it works OK May be the problem is not in maven-dependency-plugin ?
          Hide
          philipp.kunz Philipp Kunz added a comment -

          In my project only one pom is affected which has

          <plugin>
          	<groupId>org.apache.felix</groupId>
          	<artifactId>maven-bundle-plugin</artifactId>
          	<configuration>
          		<instructions>
          			<Embed-Dependency>*;scope=compile;inline=false</Embed-Dependency>
          			<Embed-Directory>lib</Embed-Directory>
          			<Embed-Transitive>true</Embed-Transitive>
          		</instructions>
          	</configuration>
          </plugin>
          

          either of those might be a clue as to how the error could be reproduced

          Show
          philipp.kunz Philipp Kunz added a comment - In my project only one pom is affected which has <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <configuration> <instructions> <Embed-Dependency>*;scope=compile;inline= false </Embed-Dependency> <Embed-Directory>lib</Embed-Directory> <Embed-Transitive> true </Embed-Transitive> </instructions> </configuration> </plugin> either of those might be a clue as to how the error could be reproduced
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user pono closed the pull request at:

          https://github.com/apache/maven-plugins/pull/31

          Show
          githubbot ASF GitHub Bot added a comment - Github user pono closed the pull request at: https://github.com/apache/maven-plugins/pull/31

            People

            • Assignee:
              Unassigned
              Reporter:
              igorf Igor Fedorenko
            • Votes:
              55 Vote for this issue
              Watchers:
              48 Start watching this issue

              Dates

              • Created:
                Updated:

                Development