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

ArchiverException when using maven dependency plugin in multi-module projects

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: unpack, unpack-dependencies
    • Labels:
      None

      Description

      Having the following module hierarchy the unpack-dependencies goal of the maven-dependency-plugin produces an ArchiverException.

      • A
        • B
        • C (depends on B)

      I took a quick look into the code and found that when unpacking the dependencies of module C the method unpack(File, File, String, String) of class org.apache.maven.plugin.dependency.AbstractDependencyMojo gets passed the target/classes directory of B as source file (instead of the created jar).

      part of the pom.xml which caused the error:

      <profile>
        <id>multi-module-coverage</id>
        <build>
          <plugins>
            <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-dependency-plugin</artifactId>
              <executions>
                <execution>
                  <id>unpack-dependencies</id>
                  <phase>process-classes</phase>
                  <goals>
                    <goal>unpack-dependencies</goal>
                  </goals>
                  <configuration>
                    <outputDirectory>${project.build.directory}/classes</outputDirectory>
                    <excludeClassifiers>tests</excludeClassifiers>
                  </configuration>
                </execution>
              </executions>
            </plugin>
          </plugins>
        </build>
      </profile>
      

      exception:

      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:266)
              at org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
              at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
              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:333)
              at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
              at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
              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:597)
              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)
      
      1. maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch
        4 kB
        Michael Berg
      2. maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact2.patch
        5 kB
        Torsten Krah
      3. mdep-194-its-aoc.diff
        14 kB
        Art O Cathain
      4. mdp-194-src-main-aoc.diff
        3 kB
        Art O Cathain
      5. plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
        7 kB
        Reimer Prochnow

        Issue Links

          Activity

          Hide
          Brett Porter added a comment -

          recent discussion has indicated that Maven may have to retain the passing in of directories even if the JAR has been built. THe dependency plugin will need to handle these more gracefully.

          Show
          Brett Porter added a comment - recent discussion has indicated that Maven may have to retain the passing in of directories even if the JAR has been built. THe dependency plugin will need to handle these more gracefully.
          Hide
          Pailin Suttiwirairat added a comment - - edited

          This issue also occur in unpack goal when I try to import the projects to eclipse (The projects has structure like above). But the exceptions are difference.

          An error message in maven console :

           
          Build errors for example-project; org.apache.maven.lifecycle.LifecycleExecutionException: 
          Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:unpack': 
          Mojo execution failed.
          

          The exception :

           
          Error log:
          !ENTRY org.maven.ide.eclipse 4 0 2009-01-26 17:49:41.784
          !MESSAGE Build errors for example-project
          !STACK 0
          org.apache.maven.lifecycle.LifecycleExecutionException: 
          Internal error in the plugin manager executing goal
          org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:unpack': Mojo execution failed.
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
          at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
          at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
          at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
          at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
          at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
          at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$MavenExecutor.execute(MavenProjectManagerImpl.java:1041)
          at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$1.execute(MavenProjectManagerImpl.java:1075)
          at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:997)
          at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:1072)
          at org.maven.ide.eclipse.internal.project.MavenProjectFacade.execute(MavenProjectFacade.java:316)
          at org.maven.ide.eclipse.internal.builder.MavenBuilder.executePostBuild(MavenBuilder.java:173)
          at org.maven.ide.eclipse.internal.builder.MavenBuilder.build(MavenBuilder.java:87)
          at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633)
          at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
          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:37)
          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.apache.maven.plugin.PluginExecutionException: Mojo execution failed.
          at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601)
          at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
          ... 28 more
          Caused by: org.apache.maven.plugin.MojoExecutionException: Unknown archiver type
          at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:236)
          at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:103)
          at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:74)
          at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
          ... 29 more
          Caused by: org.codehaus.plexus.archiver.manager.NoSuchArchiverException: No such archiver: ''.
          at org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getUnArchiver(DefaultArchiverManager.java:80)
          at org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getUnArchiver(DefaultArchiverManager.java:114)
          at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:221)
          ... 32 more
          
          Show
          Pailin Suttiwirairat added a comment - - edited This issue also occur in unpack goal when I try to import the projects to eclipse (The projects has structure like above). But the exceptions are difference. An error message in maven console : Build errors for example-project; org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:unpack': Mojo execution failed. The exception : Error log: !ENTRY org.maven.ide.eclipse 4 0 2009-01-26 17:49:41.784 !MESSAGE Build errors for example-project !STACK 0 org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:unpack': Mojo execution failed. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$MavenExecutor.execute(MavenProjectManagerImpl.java:1041) at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$1.execute(MavenProjectManagerImpl.java:1075) at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:997) at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:1072) at org.maven.ide.eclipse.internal.project.MavenProjectFacade.execute(MavenProjectFacade.java:316) at org.maven.ide.eclipse.internal.builder.MavenBuilder.executePostBuild(MavenBuilder.java:173) at org.maven.ide.eclipse.internal.builder.MavenBuilder.build(MavenBuilder.java:87) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) 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:37) 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.apache.maven.plugin.PluginExecutionException: Mojo execution failed. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498) ... 28 more Caused by: org.apache.maven.plugin.MojoExecutionException: Unknown archiver type at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:236) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:103) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:74) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579) ... 29 more Caused by: org.codehaus.plexus.archiver.manager.NoSuchArchiverException: No such archiver: ''. at org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getUnArchiver(DefaultArchiverManager.java:80) at org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getUnArchiver(DefaultArchiverManager.java:114) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:221) ... 32 more
          Hide
          Reimer Prochnow added a comment - - edited

          I have the same problem: "No such archiver '.' ". The Project builds but not inside eclipse (m2eclipse plugin). The Dependency Plugin is set up to unpack an artefact which is in fact a directory. I patched the plexus-archiver to be capable of "extracting" directories by simply copying the files inside. Ugly but working for me.
          Patch is againgst plexus-archiver-1.0-alpha-9.

          Show
          Reimer Prochnow added a comment - - edited I have the same problem: "No such archiver '.' ". The Project builds but not inside eclipse (m2eclipse plugin). The Dependency Plugin is set up to unpack an artefact which is in fact a directory. I patched the plexus-archiver to be capable of "extracting" directories by simply copying the files inside. Ugly but working for me. Patch is againgst plexus-archiver-1.0-alpha-9.
          Hide
          Gabe Beged-Dov added a comment - - edited

          I am encountering the same issue when executing unpack-dependencies in a reactor context using the test goal. I unpack dependencies in process-test-resources in order to have them available for unit-test. If I run the reactor against the package goal then the dependency projects will be packaged and unpack-dependencies will use them rather than trying to use "target/classes" and things then seem to work.

          BTW, this issue seems like a duplicate http://jira.codehaus.org/browse/MDEP-98. In that issue, Brian Fox has a comment that its not clear what should be unpacked in the case that there is no packaged artifact.

          What is a scenario where you can't use package rather than test as the goal for the reactor?

          Thanks,

          Gabe

          Show
          Gabe Beged-Dov added a comment - - edited I am encountering the same issue when executing unpack-dependencies in a reactor context using the test goal. I unpack dependencies in process-test-resources in order to have them available for unit-test. If I run the reactor against the package goal then the dependency projects will be packaged and unpack-dependencies will use them rather than trying to use "target/classes" and things then seem to work. BTW, this issue seems like a duplicate http://jira.codehaus.org/browse/MDEP-98 . In that issue, Brian Fox has a comment that its not clear what should be unpacked in the case that there is no packaged artifact. What is a scenario where you can't use package rather than test as the goal for the reactor? Thanks, Gabe
          Hide
          derek added a comment -

          As a work around here is what we did.
          In the project you want to unpack, add the maven assembly plugin to package a zip file of everything you need.

          Then in the projects that needs this resource just specify zip as the archive instead of jar. (like below)
          <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-dependency-plugin</artifactId>
          <configuration>
          <artifactItems>
          <artifactItem>
          <groupId>com.derek.mega.application</groupId>
          <artifactId>common-resources</artifactId>
          <type>zip</type>
          <overWrite>true</overWrite>
          <outputDirectory>target/common-resources</outputDirectory>
          <includes>*/.properties,*/.xml,*/.sql,*/.bat,*/.sh</includes>
          </artifactItem>
          </artifactItems>
          </configuration>
          <executions>
          <execution>
          <id>unpack-common-resources</id>
          <goals>
          <goal>unpack</goal>
          </goals>
          <phase>generate-resources</phase>
          </execution>
          </executions>
          </plugin>

          Show
          derek added a comment - As a work around here is what we did. In the project you want to unpack, add the maven assembly plugin to package a zip file of everything you need. Then in the projects that needs this resource just specify zip as the archive instead of jar. (like below) <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <configuration> <artifactItems> <artifactItem> <groupId>com.derek.mega.application</groupId> <artifactId>common-resources</artifactId> <type>zip</type> <overWrite>true</overWrite> <outputDirectory>target/common-resources</outputDirectory> <includes>* / .properties,* / .xml,* / .sql,* / .bat,* / .sh</includes> </artifactItem> </artifactItems> </configuration> <executions> <execution> <id>unpack-common-resources</id> <goals> <goal>unpack</goal> </goals> <phase>generate-resources</phase> </execution> </executions> </plugin>
          Hide
          Thiago Leão Moreira added a comment -

          This is the exactly problem that I have. Any intention to fix it? I'm using the version 2.1

          Show
          Thiago Leão Moreira added a comment - This is the exactly problem that I have. Any intention to fix it? I'm using the version 2.1
          Hide
          Archimedes Trajano added a comment -

          This is specifically for UNPACK goal

          I think what could be done is to change the check so that if it detects that the source is a directory rather than an archive that it will just copy from the directory instead of trying to extract.

          Show
          Archimedes Trajano added a comment - This is specifically for UNPACK goal I think what could be done is to change the check so that if it detects that the source is a directory rather than an archive that it will just copy from the directory instead of trying to extract.
          Hide
          Michael Berg added a comment - - edited

          I have experienced the same issue, but I would like to offer an alternative patch. I do not feel that the proper place to fix this problem is in the plexus unarchiver simply because that is where the exception manifests itself. The underlying issue is that the unpacker is being told to unpack a directory, which really does not make sense. Also, making such a change in the archiver could lead to regression issues elsewhere.

          My patch is directed at the UnpackMojo itself, adding a check to see if the archive is really an archive or a directory, and in case of the latter, use the relevant plexus FileUtils method to copy the files over, rather than the archiver. It seems like a more logical choice to me.

          This patch more or less implements the suggestion made by Archimedes Trajano above.

          Show
          Michael Berg added a comment - - edited I have experienced the same issue, but I would like to offer an alternative patch. I do not feel that the proper place to fix this problem is in the plexus unarchiver simply because that is where the exception manifests itself. The underlying issue is that the unpacker is being told to unpack a directory, which really does not make sense. Also, making such a change in the archiver could lead to regression issues elsewhere. My patch is directed at the UnpackMojo itself, adding a check to see if the archive is really an archive or a directory, and in case of the latter, use the relevant plexus FileUtils method to copy the files over, rather than the archiver. It seems like a more logical choice to me. This patch more or less implements the suggestion made by Archimedes Trajano above.
          Hide
          Michael Berg added a comment - - edited

          See maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch

          Show
          Michael Berg added a comment - - edited See maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch
          Hide
          Art O Cathain added a comment -

          I like your patch Michael, but I think it doesn't work if your artifactItem's <includes> have a subdirectory e.g.
          <includes>xsd/*.xsd</includes>

          In this case the unpacker puts the xsd files in [outputdirectory]/xsd/, but the fileutils copy method (from your patch) puts them directly in [outputdirectory].

          Show
          Art O Cathain added a comment - I like your patch Michael, but I think it doesn't work if your artifactItem's <includes> have a subdirectory e.g. <includes>xsd/*.xsd</includes> In this case the unpacker puts the xsd files in [outputdirectory] /xsd/, but the fileutils copy method (from your patch) puts them directly in [outputdirectory] .
          Hide
          Michael Berg added a comment - - edited

          Art, have you actually witnessed this? I have the following in my pom:

          <goals>
          <goal>unpack</goal>
          </goals>
          <configuration>
          <artifactItems>
          <artifactItem>
          <groupId>com.interform400.xml</groupId>
          <artifactId>plugin-web-base</artifactId>
          <version>$

          {project.version}

          </version>
          <type>war</type>
          </artifactItem>
          </artifactItems>
          <includes>**/web.xml</includes>
          <outputDirectory>$

          {project.build.directory}

          /plugin-web-base-unpack</outputDirectory>
          </configuration>

          When the build finishes, then inside the plugin-web-base-unpack folder I am seeing this:

          plugin-web-base-unpack/
          /WEB-INF/
          /WEB-INF/web.xml

          The WEB-INF folder was created automatically.

          Show
          Michael Berg added a comment - - edited Art, have you actually witnessed this? I have the following in my pom: <goals> <goal>unpack</goal> </goals> <configuration> <artifactItems> <artifactItem> <groupId>com.interform400.xml</groupId> <artifactId>plugin-web-base</artifactId> <version>$ {project.version} </version> <type>war</type> </artifactItem> </artifactItems> <includes>**/web.xml</includes> <outputDirectory>$ {project.build.directory} /plugin-web-base-unpack</outputDirectory> </configuration> When the build finishes, then inside the plugin-web-base-unpack folder I am seeing this: plugin-web-base-unpack/ /WEB-INF/ /WEB-INF/web.xml The WEB-INF folder was created automatically.
          Hide
          Art O Cathain added a comment -

          Yeah, it's happening to me. I could try and make you a sample project? In your version, your <includes> doesn't have any subdirectories directly defined in it, so I'd expect it to work.

          Maybe as a workaround I could try the ** notation.

          Show
          Art O Cathain added a comment - Yeah, it's happening to me. I could try and make you a sample project? In your version, your <includes> doesn't have any subdirectories directly defined in it, so I'd expect it to work. Maybe as a workaround I could try the ** notation.
          Hide
          Art O Cathain added a comment -

          Using ** makes no difference. I'm using type jar, you're using type war - could that be it?

          Show
          Art O Cathain added a comment - Using ** makes no difference. I'm using type jar, you're using type war - could that be it?
          Hide
          Michael Berg added a comment -

          I would not think the dependency type mattered. The source directory should contain the already unpacked archive regardless of its type.

          However, in my case I am building a war file rather than a jar file, perhaps that matters?

          Show
          Michael Berg added a comment - I would not think the dependency type mattered. The source directory should contain the already unpacked archive regardless of its type. However, in my case I am building a war file rather than a jar file, perhaps that matters?
          Hide
          Art O Cathain added a comment -

          It's happening to me with both war and jar types of project (in both cases the dependency is on a jar project)

          Show
          Art O Cathain added a comment - It's happening to me with both war and jar types of project (in both cases the dependency is on a jar project)
          Hide
          Torsten Krah added a comment -

          CopyMojo does need the same patch like UnpackMojo.

          Show
          Torsten Krah added a comment - CopyMojo does need the same patch like UnpackMojo.
          Hide
          Torsten Krah added a comment -

          Addition:

          The problem with prefix annotation is still there, using something like "solr/**" does result in those directories not being created.

          Show
          Torsten Krah added a comment - Addition: The problem with prefix annotation is still there, using something like "solr/**" does result in those directories not being created.
          Hide
          Michael Berg added a comment - - edited

          Isn't it supposed to work that way? From a shell analogy, consider this:

          $ cp /some/dir/* localdir/

          I would not expect /some/dir to be created under localdir/ in this case.

          Have you tried entering /solr/** / *

          (remove the spaces, I have to enter them or the comment system thinks I'm trying to enter something in bold)

          Show
          Michael Berg added a comment - - edited Isn't it supposed to work that way? From a shell analogy, consider this: $ cp /some/dir/* localdir/ I would not expect /some/dir to be created under localdir/ in this case. Have you tried entering /solr/** / * (remove the spaces, I have to enter them or the comment system thinks I'm trying to enter something in bold)
          Hide
          Torsten Krah added a comment -

          Thats correct, but i would want - i dont know how to do it yet - this one:

          cp -R solr/ localdir/

          I'll try the alternative.

          Show
          Torsten Krah added a comment - Thats correct, but i would want - i dont know how to do it yet - this one: cp -R solr/ localdir/ I'll try the alternative.
          Hide
          Art O Cathain added a comment -

          @Michael Either way seems reasonable to me, but the problem is that the files end up in a different directory depending on whether you do "mvn compile" (which didn't work at all before your patch) or "mvn install" (which did work). For compatibility I think it has to work the way it currently does in "mvn install".

          Show
          Art O Cathain added a comment - @Michael Either way seems reasonable to me, but the problem is that the files end up in a different directory depending on whether you do "mvn compile" (which didn't work at all before your patch) or "mvn install" (which did work). For compatibility I think it has to work the way it currently does in "mvn install".
          Hide
          Michael Berg added a comment -

          @Art Actually "mvn install" did not work either for me, before the patch. That's how I noticed the problem in the first place, our CI server began to fail for no apparent reason during an "mvn install" build.

          I think "how it works" is the same regardless of which maven phase the unpack goal is bound to. It should be able to unpack files regardless.

          Show
          Michael Berg added a comment - @Art Actually "mvn install" did not work either for me, before the patch. That's how I noticed the problem in the first place, our CI server began to fail for no apparent reason during an "mvn install" build. I think "how it works" is the same regardless of which maven phase the unpack goal is bound to. It should be able to unpack files regardless.
          Hide
          Art O Cathain added a comment -

          Thanks for your work on this Michael. Would it help if I created a small self-contained project that demonstrates the experience I've been having?

          Show
          Art O Cathain added a comment - Thanks for your work on this Michael. Would it help if I created a small self-contained project that demonstrates the experience I've been having?
          Hide
          Gili added a comment -

          Four years and counting. If you're not going to fix it anytime soon, please provide a workaround! What are we supposed to do?

          Show
          Gili added a comment - Four years and counting. If you're not going to fix it anytime soon, please provide a workaround! What are we supposed to do?
          Hide
          Gili added a comment -

          Grr. Note to self, this error also occurs if you attempt to unpack a dependency that requires a classifier but you omit it. Meaning, if you have:

          • A
            • B (classifier = foo)
            • C (attempts to unpack B but without a classifier)

          then C will throw an exception. If you add the classifier, however, it works.

          Show
          Gili added a comment - Grr. Note to self, this error also occurs if you attempt to unpack a dependency that requires a classifier but you omit it. Meaning, if you have: A B (classifier = foo) C (attempts to unpack B but without a classifier) then C will throw an exception. If you add the classifier, however, it works.
          Hide
          Art O Cathain added a comment - - edited

          I have a new patch, based on Nicolas Cornaglia's patch C attached to MDEP-187.

          Show
          Art O Cathain added a comment - - edited I have a new patch, based on Nicolas Cornaglia's patch C attached to MDEP-187 .
          Hide
          Art O Cathain added a comment -

          I have also created some integration tests

          Show
          Art O Cathain added a comment - I have also created some integration tests
          Hide
          Hervé Boutemy added a comment -

          duplicate of MDEP-98: closing this duplicate will help focus everybody's energy

          Show
          Hervé Boutemy added a comment - duplicate of MDEP-98 : closing this duplicate will help focus everybody's energy

            People

            • Assignee:
              Unassigned
              Reporter:
              Sascha Rodekamp
            • Votes:
              45 Vote for this issue
              Watchers:
              30 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development