ArchiverException when using maven dependency plugin in multi-module projects

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.

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

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.

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

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>

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

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.

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.

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

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].

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>$

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

/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.

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.

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

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?

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

CopyMojo does need the same patch like UnpackMojo.

Addition:

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

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)

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.

@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".

@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.

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?

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

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.

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

I have also created some integration tests

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