Maven Dependency Plugin
  1. Maven Dependency Plugin
  2. MDEP-98

dependency:unpack: The source must not be a directory

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 2.0-alpha-4
    • Fix Version/s: None
    • Component/s: unpack, unpack-dependencies
    • Labels:
      None
    • Environment:
      Windows XP Professional SP2
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
      Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)

      Description

      Using maven-dependency-plugin in a multimodule project inside a module wich has a dependency with another module in the same project the next error ocurrs :

      org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
              at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
              at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
              at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
              at org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
              at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
              at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
              at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
              at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
              at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
              at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
              at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
              at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
              at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
              at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              at java.lang.reflect.Method.invoke(Method.java:585)
              at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
              at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
              at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
              at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Error unpacking file: c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to: c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes
      org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.

      Project structure is as follows:

      plataforma

      • platform-core
      • platform-bundle
      • platform-bundle-jar
      • platform-bundle-src

      and the error happens on executing any goal from parent pom. maven-dependency-plugin seems to receive a reference to target/classes directory for platform-core dependency instead of the URL to my local repository where platform-core is located.

      1. MDEP-98-ITs.patch
        10 kB
        Stevo Slavic
      2. mdep98-testcase-parent.zip
        15 kB
        Antonio Petrelli
      3. mdep98-testcase-parent-with-surefire.zip
        15 kB
        Antonio Petrelli

        Issue Links

          Activity

          Hide
          Brian E. Fox added a comment -

          can you please attach a sample project to reproduce this?

          Show
          Brian E. Fox added a comment - can you please attach a sample project to reproduce this?
          Hide
          Brian E. Fox added a comment -

          i can reproduce this with the IT now. This only happens on multi project builds where the artifact is in the same reactor and the compile phase is used. Normally you will want to do install for multimodule builds to work. The best I can do is detect I've been given a folder and copy the contents of that folder instead of unpacking it. It's not clear what to do on copy since you would normally expect the jar not the classes themselves.

          Show
          Brian E. Fox added a comment - i can reproduce this with the IT now. This only happens on multi project builds where the artifact is in the same reactor and the compile phase is used. Normally you will want to do install for multimodule builds to work. The best I can do is detect I've been given a folder and copy the contents of that folder instead of unpacking it. It's not clear what to do on copy since you would normally expect the jar not the classes themselves.
          Hide
          Marcus Linke added a comment -

          Not sure if this is the right place to post this but I'm also run into this problem while using the newest M2Eclipse development version (0.9.9.2009111711) with Eclipse 3.5 and activated workspace resolution. When switching off workspace resolution the error doesnt occur. Here is the stacktrace:

          !ENTRY org.maven.ide.eclipse 4 0 2009-12-03 09:48:49.557
          !MESSAGE Build errors for mb-businesscore-de
          !STACK 0
          org.apache.maven.plugin.MojoExecutionException: Error unpacking file: /Users/marcus/workspace/mb-ordercore/target/classes to: /Users/marcus/workspace/mb-businesscore-de/target/tmp-hbm-additional-sources

          org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
          at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:269)
          at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
          at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
          at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:547)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317)
          at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:239)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102)
          at org.maven.ide.eclipse.internal.embedder.MavenImpl.execute(MavenImpl.java:203)
          at org.maven.ide.eclipse.internal.project.GenericBuildParticipant.executePostBuild(GenericBuildParticipant.java:139)
          at org.maven.ide.eclipse.internal.project.GenericBuildParticipant.build(GenericBuildParticipant.java:78)
          at org.maven.ide.eclipse.internal.builder.MavenBuilder.build(MavenBuilder.java:149)
          at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627)
          at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
          at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
          at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
          at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
          at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
          at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
          at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309)
          at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341)
          at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140)
          at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
          at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
          Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
          at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
          at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
          at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260)
          ... 23 more
          !SESSION 2009-12-03 10:00:29.933 -----------------------------------------------
          eclipse.buildId=M20090917-0800
          java.version=1.5.0_20
          java.vendor=Apple Inc.
          BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=de_DE
          Framework arguments: -product org.eclipse.epp.package.jee.product -keyring /Users/marcus/.eclipse_keyring -showlocation
          Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/marcus/.eclipse_keyring -showlocation

          Show
          Marcus Linke added a comment - Not sure if this is the right place to post this but I'm also run into this problem while using the newest M2Eclipse development version (0.9.9.2009111711) with Eclipse 3.5 and activated workspace resolution. When switching off workspace resolution the error doesnt occur. Here is the stacktrace: !ENTRY org.maven.ide.eclipse 4 0 2009-12-03 09:48:49.557 !MESSAGE Build errors for mb-businesscore-de !STACK 0 org.apache.maven.plugin.MojoExecutionException: Error unpacking file: /Users/marcus/workspace/mb-ordercore/target/classes to: /Users/marcus/workspace/mb-businesscore-de/target/tmp-hbm-additional-sources org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:269) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:547) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:239) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102) at org.maven.ide.eclipse.internal.embedder.MavenImpl.execute(MavenImpl.java:203) at org.maven.ide.eclipse.internal.project.GenericBuildParticipant.executePostBuild(GenericBuildParticipant.java:139) at org.maven.ide.eclipse.internal.project.GenericBuildParticipant.build(GenericBuildParticipant.java:78) at org.maven.ide.eclipse.internal.builder.MavenBuilder.build(MavenBuilder.java:149) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174) at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260) ... 23 more !SESSION 2009-12-03 10:00:29.933 ----------------------------------------------- eclipse.buildId=M20090917-0800 java.version=1.5.0_20 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product -keyring /Users/marcus/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/marcus/.eclipse_keyring -showlocation
          Hide
          Nathan Wells added a comment -

          Is this a duplicate of MDEP-187?

          Show
          Nathan Wells added a comment - Is this a duplicate of MDEP-187 ?
          Hide
          Thiago Leão Moreira added a comment -

          Is there any intention to fix this?

          Show
          Thiago Leão Moreira added a comment - Is there any intention to fix this?
          Hide
          Ed Staub added a comment -

          Sigh... 4 years and no fix.
          What's the right thing to do here?
          Should unpack perhaps do a copy when it encounters a directory?

          Show
          Ed Staub added a comment - Sigh... 4 years and no fix. What's the right thing to do here? Should unpack perhaps do a copy when it encounters a directory?
          Hide
          René Zanner added a comment -

          sure - that's logical. "i want the content of X in some folder." (i don't care whether X is an archive or a folder - just like windows displaying zip files as "compressed folders"). definitely better than to break the build...

          Show
          René Zanner added a comment - sure - that's logical. "i want the content of X in some folder." (i don't care whether X is an archive or a folder - just like windows displaying zip files as "compressed folders"). definitely better than to break the build...
          Hide
          Stevo Slavic added a comment -

          Here's a patch MDEP-98-ITs.patch with integration test for unpacking dependencies from reactor.

          Show
          Stevo Slavic added a comment - Here's a patch MDEP-98-ITs.patch with integration test for unpacking dependencies from reactor.
          Hide
          Stevo Slavic added a comment -

          ITs prove that the maven-dependency-plugin works well, as designed. This is practically m2e issue.

          By combining profiles and maven-resource-plugin:copy-resources I've managed to workaround this issue.

          In a multi-module project there is a shared resources module (SRM). Other modules which reference SRM and need it's content unpacked have two profiles, non-m2e and m2e, former activated when m2e.version property is not defined and latter activated when m2e.version property is defined. In non-m2e profile maven-dependency-plugin:unpack-dependencies unpacks SRM, while in m2e profile maven-resources-plugin:copy-resources is configured to copy shared resources from SRM.

          When build is run using maven on command line, m2e.version is not defined and maven-dependency-plugin will unpack SRM dependency from reactor. When build is run from eclipse using m2e, m2e.version is defined and m2e will copy resources.

          Removing my vote.

          Show
          Stevo Slavic added a comment - ITs prove that the maven-dependency-plugin works well, as designed. This is practically m2e issue. By combining profiles and maven-resource-plugin:copy-resources I've managed to workaround this issue. In a multi-module project there is a shared resources module (SRM). Other modules which reference SRM and need it's content unpacked have two profiles, non-m2e and m2e, former activated when m2e.version property is not defined and latter activated when m2e.version property is defined. In non-m2e profile maven-dependency-plugin:unpack-dependencies unpacks SRM, while in m2e profile maven-resources-plugin:copy-resources is configured to copy shared resources from SRM. When build is run using maven on command line, m2e.version is not defined and maven-dependency-plugin will unpack SRM dependency from reactor. When build is run from eclipse using m2e, m2e.version is defined and m2e will copy resources. Removing my vote.
          Hide
          Antonio Petrelli added a comment -

          It happens out of m2e too.
          I have a multi-module project of this type:
          parent
          +-- jar (JNLP client)
          +-- war (unpacks JNLP client)
          +-- ear (pack web)

          During "mvn site" call, the "unpack" goal breaks in the way shown above.
          I will try to create a test case for this.

          Show
          Antonio Petrelli added a comment - It happens out of m2e too. I have a multi-module project of this type: parent +-- jar (JNLP client) +-- war (unpacks JNLP client) +-- ear (pack web) During "mvn site" call, the "unpack" goal breaks in the way shown above. I will try to create a test case for this.
          Hide
          Antonio Petrelli added a comment - - edited

          Sorry for the noise, it seems that the unpack was triggered in some ways by the Cobertura plugin. I thought that a workaround was to put the dependency to unpack as a provided dependency, however it does not work (I made some mistakes before).

          Show
          Antonio Petrelli added a comment - - edited Sorry for the noise, it seems that the unpack was triggered in some ways by the Cobertura plugin. I thought that a workaround was to put the dependency to unpack as a provided dependency, however it does not work (I made some mistakes before).
          Hide
          Antonio Petrelli added a comment -

          Added test case to reproduce the problem. Cobertura plugin triggers the WAR build that fails to unpack a dependency.

          Show
          Antonio Petrelli added a comment - Added test case to reproduce the problem. Cobertura plugin triggers the WAR build that fails to unpack a dependency.
          Hide
          Antonio Petrelli added a comment -

          Added testcase that uses Surefire report instead of Cobertura. So this seems not to be a Cobertura plugin related bug.
          Probably, it's the way the build is triggered that make it fail.
          However, the workaround is doing an "mvn package" before doing "mvn site". It seems that this way the WAR is not rebuilt and, therefore, the "unpack" goal is not called.

          Show
          Antonio Petrelli added a comment - Added testcase that uses Surefire report instead of Cobertura. So this seems not to be a Cobertura plugin related bug. Probably, it's the way the build is triggered that make it fail. However, the workaround is doing an "mvn package" before doing "mvn site". It seems that this way the WAR is not rebuilt and, therefore, the "unpack" goal is not called.
          Hide
          Stevo Slavic added a comment -

          I've reproduced this using attached surefire test case. [1] is relevant build log with error when running just mvn site.

          With this command one runs site phase of site lifecycle to which by default maven-site-plugin site} goal is bound to. Site plugin site goal runs {{test phase of default lifecycle. package phase, to which assembly of jar module zip archive with bin classifier is bound, will not be triggered by this test phase execution, but process-resources in war module, to which unpacking of that bin/zip is bound, will be triggered. IMO it's wrong that dependency plugin manages to resolve jar module from reactor - it should try to resolve one with bin classifier (and not main jar module), and in that case I'd expect build to fail with missing dependency reported since jar module with bin classifier creation has not been triggered and thus it's not attached to the build.

          It's strange to me also that if you run "mvn package" as one build, and then "mvn site" as separate build that dependency plugin in "site" build will be able to resolve jar module bin classifier artifact and unpack it even though it's not installed on any repository nor is it in reactor of "site" build. Looks like a bug too, again related to resolving dependencies.

          [1] build log

          [INFO] ------------------------------------------------------------------------
          [INFO] Building MDEP-98 test case - WAR 1.0.0-SNAPSHOT
          [INFO] ------------------------------------------------------------------------
          [INFO]
          [INFO] --- maven-site-plugin:3.0:site (default-site) @ mdep98-testcase-web ---
          [INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.4
          [INFO] configuring report plugin org.apache.maven.plugins:maven-surefire-report-plugin:2.10
          [INFO]
          [INFO] >>> maven-surefire-report-plugin:2.10:report-only (report:report-only) @ mdep98-testcase-web >>>
          [INFO]
          [INFO] <<< maven-surefire-report-plugin:2.10:report-only (report:report-only) @ mdep98-testcase-web <<<
          [INFO]
          [INFO] >>> maven-surefire-report-plugin:2.10:report (report:report) @ mdep98-testcase-web >>>
          [INFO]
          [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ mdep98-testcase-web ---
          [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
          [INFO] Copying 0 resource
          [INFO]
          [INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web ---
          [INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip
          [INFO] Unpacking D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-jar\target\classes to
            D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-web\target\mdep98-testcase-web-1.0.0-SNAPSHOT\webstart
             with includes null and excludes:null
          org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
                  at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
                  at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
                  at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260)
                  at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
                  at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
                  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
                  at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
                  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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:175
          )
                  at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildReportPlugin(DefaultMavenReportExecutor.java:
          282)
                  at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:
          148)
                  at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:240)
          
          Show
          Stevo Slavic added a comment - I've reproduced this using attached surefire test case. [1] is relevant build log with error when running just mvn site . With this command one runs site phase of site lifecycle to which by default maven-site-plugin site} goal is bound to. Site plugin site goal runs {{test phase of default lifecycle. package phase, to which assembly of jar module zip archive with bin classifier is bound, will not be triggered by this test phase execution, but process-resources in war module, to which unpacking of that bin/zip is bound, will be triggered. IMO it's wrong that dependency plugin manages to resolve jar module from reactor - it should try to resolve one with bin classifier (and not main jar module), and in that case I'd expect build to fail with missing dependency reported since jar module with bin classifier creation has not been triggered and thus it's not attached to the build. It's strange to me also that if you run "mvn package" as one build, and then "mvn site" as separate build that dependency plugin in "site" build will be able to resolve jar module bin classifier artifact and unpack it even though it's not installed on any repository nor is it in reactor of "site" build. Looks like a bug too, again related to resolving dependencies. [1] build log [INFO] ------------------------------------------------------------------------ [INFO] Building MDEP-98 test case - WAR 1.0.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-site-plugin:3.0:site (default-site) @ mdep98-testcase-web --- [INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.4 [INFO] configuring report plugin org.apache.maven.plugins:maven-surefire-report-plugin:2.10 [INFO] [INFO] >>> maven-surefire-report-plugin:2.10:report-only (report:report-only) @ mdep98-testcase-web >>> [INFO] [INFO] <<< maven-surefire-report-plugin:2.10:report-only (report:report-only) @ mdep98-testcase-web <<< [INFO] [INFO] >>> maven-surefire-report-plugin:2.10:report (report:report) @ mdep98-testcase-web >>> [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ mdep98-testcase-web --- [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! [INFO] Copying 0 resource [INFO] [INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web --- [INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip [INFO] Unpacking D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-jar\target\classes to D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-web\target\mdep98-testcase-web-1.0.0-SNAPSHOT\webstart with includes null and excludes:null org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory. at org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174) at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:175 ) at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildReportPlugin(DefaultMavenReportExecutor.java: 282) at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java: 148) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:240)
          Hide
          Antonio Petrelli added a comment -

          Stevo, just a comment about the last sentence about "mvn package" and "mvn site".
          I don't think that unpack goal is run and it succeeds, but I think that the report executor notices that the build has been already done, and then it does not retry to build it. So it succeeds simply because the unpack does not run.

          Show
          Antonio Petrelli added a comment - Stevo, just a comment about the last sentence about "mvn package" and "mvn site". I don't think that unpack goal is run and it succeeds, but I think that the report executor notices that the build has been already done, and then it does not retry to build it. So it succeeds simply because the unpack does not run.
          Hide
          Stevo Slavic added a comment -

          In "site" build after "package" build maven-dependency-plugin reports that classes were already unpacked:

          [INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web ---
          [INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip
          [INFO] classes already unpacked.
          
          Show
          Stevo Slavic added a comment - In "site" build after "package" build maven-dependency-plugin reports that classes were already unpacked: [INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web --- [INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip [INFO] classes already unpacked.
          Hide
          Antonio Petrelli added a comment -

          Whoops! Sorry Stevo you're right, thank you.

          Show
          Antonio Petrelli added a comment - Whoops! Sorry Stevo you're right, thank you.
          Hide
          Idcmp added a comment -

          This is pretty simple to reproduce with mvn site.

          What's the recommended workaround?

          Show
          Idcmp added a comment - This is pretty simple to reproduce with mvn site. What's the recommended workaround?
          Hide
          Emmanuel Lecharny added a comment -

          get ready for the 5 years anniversary of this bug !!!

          Ok, seriously, what you guys need to get it fixed ?

          Show
          Emmanuel Lecharny added a comment - get ready for the 5 years anniversary of this bug !!! Ok, seriously, what you guys need to get it fixed ?
          Hide
          Nathan Wells added a comment -

          My solution: stop using Maven.

          Show
          Nathan Wells added a comment - My solution: stop using Maven.
          Hide
          Art O Cathain added a comment -

          There is some more activity on the duplicate MDEP-194. Can you try the patch there?

          Show
          Art O Cathain added a comment - There is some more activity on the duplicate MDEP-194 . Can you try the patch there?
          Hide
          Hervé Boutemy added a comment -

          like MDEP-187, error message improved in r1368261
          this doesn't fix the problem but at least makes it easier to track
          notice that another corner case to take care is when the dependency to unpack has a classifier/specific packaging: we can't imagine the content before the artifact has been packaged

          Show
          Hervé Boutemy added a comment - like MDEP-187 , error message improved in r1368261 this doesn't fix the problem but at least makes it easier to track notice that another corner case to take care is when the dependency to unpack has a classifier/specific packaging: we can't imagine the content before the artifact has been packaged
          Hide
          James Davis added a comment -

          Any progress on this? This is a rather serious bug that seems to be causing a bit of trouble. As stated above, I would expect if it is a directory it should just be copied. Also there is a possible patch that has been mentioned, but nobody seems to be indicating it has been tried out.

          Show
          James Davis added a comment - Any progress on this? This is a rather serious bug that seems to be causing a bit of trouble. As stated above, I would expect if it is a directory it should just be copied. Also there is a possible patch that has been mentioned, but nobody seems to be indicating it has been tried out.
          Hide
          James Davis added a comment - - edited

          As far as the comment about needing to do an install on the modules, that is not always a desirable thing to do. If you have multiple builds running on the same box with each of them installing, your build may end up getting the artifact published by the other build, not the one from this build. The only way to ensure you have the right contents is to use the artifact from the same workspace.

          As a side-note, I updated to the latest version (2.5) and used the package goal and all seems to be working.

          Show
          James Davis added a comment - - edited As far as the comment about needing to do an install on the modules, that is not always a desirable thing to do. If you have multiple builds running on the same box with each of them installing, your build may end up getting the artifact published by the other build, not the one from this build. The only way to ensure you have the right contents is to use the artifact from the same workspace. As a side-note, I updated to the latest version (2.5) and used the package goal and all seems to be working.
          Hide
          Michal Rembiszewski added a comment -

          I had this issue also with sonar:sonar. There is a simple workaround which could be applicable for some other scenarios as well. The problem is unpack will attempt to use folder as its source only if package was not executed for this module as part of the build.

          So in my case the workaround was to run "mvn package sonar:sonar" instead of "mvn sonar:sonar". The former does certain things twice so it's less effective, but when reactor detects package was performed, it will unpack dependencies from jar instead of going for the folder. Probably the workaround can be improved through explicit package execution.

          Show
          Michal Rembiszewski added a comment - I had this issue also with sonar:sonar. There is a simple workaround which could be applicable for some other scenarios as well. The problem is unpack will attempt to use folder as its source only if package was not executed for this module as part of the build. So in my case the workaround was to run "mvn package sonar:sonar" instead of "mvn sonar:sonar". The former does certain things twice so it's less effective, but when reactor detects package was performed, it will unpack dependencies from jar instead of going for the folder. Probably the workaround can be improved through explicit package execution.
          Hide
          Samuel Langlois added a comment -

          For Sonar, the "official" workaround is to use the sonar.phase parameter, asking Sonar to run the build up to a certain phase:

          mvn sonar:sonar -Dsonar.phase=package
          

          This is probably quite similar to the previous comment, and of course it runs the tests twice.

          (I must confess I sometimes move the goal that packages from the package phase to the process-test-classes phase, so that I only have to build up to that phase, avoiding the test phase. Shame on me...)

          Show
          Samuel Langlois added a comment - For Sonar, the "official" workaround is to use the sonar.phase parameter, asking Sonar to run the build up to a certain phase: mvn sonar:sonar -Dsonar.phase= package This is probably quite similar to the previous comment, and of course it runs the tests twice. (I must confess I sometimes move the goal that packages from the package phase to the process-test-classes phase, so that I only have to build up to that phase, avoiding the test phase. Shame on me...)

            People

            • Assignee:
              Unassigned
              Reporter:
              Pablo Muñiz
            • Votes:
              34 Vote for this issue
              Watchers:
              28 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development