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

dependency:unpack: The source must not be a directory

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • 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)
    • Number of attachments :
      3

      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

        Issue Links

          Activity

          Hide
          Herve 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
          Herve 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:
              51 Vote for this issue
              Watchers:
              43 Start watching this issue

              Dates

              • Created:
                Updated: