[
http://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=184011#action_184011
]
Gabe Beged-Dov edited comment on MDEP-194 at 7/18/09 12:37 PM:
---------------------------------------------------------------
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.
IWhat is a scenario where you can't use package rather than test as the goal
for the reactor?
Thanks,
Gabe
was (Author: gabe97330):
I am encountering the same issue when executing unpack-dependencies in a
reactor context. It doesn't occur in the direct execution context since it
operates against the artifact in the local repository. Is there any workaround
that would allow unpacking of dependencies in the reactor context using the
release version of the archiver? Any thought on when an update of the archiver
might be available?
Thanks,
Gabe
> ArchiverException when using maven dependency plugin in multi-module projects
> -----------------------------------------------------------------------------
>
> Key: MDEP-194
> URL: http://jira.codehaus.org/browse/MDEP-194
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Affects Versions: 2.0
> Reporter: Sascha Hofer
> Attachments: 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
