Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Duplicate
-
Affects Version/s: 2.0
-
Fix Version/s: None
-
Component/s: unpack, unpack-dependencies
-
Labels:None
-
Number of attachments :
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)
Issue Links
- duplicates
-
MDEP-98
dependency:unpack: The source must not be a directory
-
- is duplicated by
-
MDEP-354
dependency:unpack-dependencies fail if artifact is à directory
-
- is related to
-
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
-
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.