You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Berg (JIRA)" <ji...@codehaus.org> on 2011/11/25 11:58:40 UTC

[jira] Issue Comment Edited: (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects

    [ https://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284239#comment-284239 ] 

Michael Berg edited comment on MDEP-194 at 11/25/11 4:58 AM:
-------------------------------------------------------------

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.

      was (Author: mberg2007):
    Patches the mojo to handle unpacked archives
  
> ArchiverException when using maven dependency plugin in multi-module projects
> -----------------------------------------------------------------------------
>
>                 Key: MDEP-194
>                 URL: https://jira.codehaus.org/browse/MDEP-194
>             Project: Maven 2.x Dependency Plugin
>          Issue Type: Bug
>    Affects Versions: 2.0
>            Reporter: Sascha Hofer
>         Attachments: maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch, plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
>
>
> 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:
> {noformat}
> <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>
> {noformat}
> exception:
> {noformat}
> 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)
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira