dependency:unpack: The source must not be a directory

can you please attach a sample project to reproduce this?

i can reproduce this with the IT now. This only happens on multi project builds where the artifact is in the same reactor and the compile phase is used. Normally you will want to do install for multimodule builds to work. The best I can do is detect I've been given a folder and copy the contents of that folder instead of unpacking it. It's not clear what to do on copy since you would normally expect the jar not the classes themselves.

Not sure if this is the right place to post this but I'm also run into this problem while using the newest M2Eclipse development version (0.9.9.2009111711) with Eclipse 3.5 and activated workspace resolution. When switching off workspace resolution the error doesnt occur. Here is the stacktrace:

!ENTRY org.maven.ide.eclipse 4 0 2009-12-03 09:48:49.557
!MESSAGE Build errors for mb-businesscore-de
!STACK 0
org.apache.maven.plugin.MojoExecutionException: Error unpacking file: /Users/marcus/workspace/mb-ordercore/target/classes to: /Users/marcus/workspace/mb-businesscore-de/target/tmp-hbm-additional-sources

org.codehaus.plexus.archiver.ArchiverException: The source must not be a directory.
at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:269)
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:547)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:239)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102)
at org.maven.ide.eclipse.internal.embedder.MavenImpl.execute(MavenImpl.java:203)
at org.maven.ide.eclipse.internal.project.GenericBuildParticipant.executePostBuild(GenericBuildParticipant.java:139)
at org.maven.ide.eclipse.internal.project.GenericBuildParticipant.build(GenericBuildParticipant.java:78)
at org.maven.ide.eclipse.internal.builder.MavenBuilder.build(MavenBuilder.java:149)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
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:42)
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.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:260)
... 23 more
!SESSION 2009-12-03 10:00:29.933 -----------------------------------------------
eclipse.buildId=M20090917-0800
java.version=1.5.0_20
java.vendor=Apple Inc.
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=de_DE
Framework arguments: -product org.eclipse.epp.package.jee.product -keyring /Users/marcus/.eclipse_keyring -showlocation
Command-line arguments: -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/marcus/.eclipse_keyring -showlocation

Is this a duplicate of MDEP-187?

Is there any intention to fix this?

Sigh... 4 years and no fix.
What's the right thing to do here?
Should unpack perhaps do a copy when it encounters a directory?

sure - that's logical. "i want the content of X in some folder." (i don't care whether X is an archive or a folder - just like windows displaying zip files as "compressed folders"). definitely better than to break the build...

Here's a patch MDEP-98-ITs.patch with integration test for unpacking dependencies from reactor.

ITs prove that the maven-dependency-plugin works well, as designed. This is practically m2e issue.

By combining profiles and maven-resource-plugin:copy-resources I've managed to workaround this issue.

In a multi-module project there is a shared resources module (SRM). Other modules which reference SRM and need it's content unpacked have two profiles, non-m2e and m2e, former activated when m2e.version property is not defined and latter activated when m2e.version property is defined. In non-m2e profile maven-dependency-plugin:unpack-dependencies unpacks SRM, while in m2e profile maven-resources-plugin:copy-resources is configured to copy shared resources from SRM.

When build is run using maven on command line, m2e.version is not defined and maven-dependency-plugin will unpack SRM dependency from reactor. When build is run from eclipse using m2e, m2e.version is defined and m2e will copy resources.

Removing my vote.

It happens out of m2e too.
I have a multi-module project of this type:
parent
+-- jar (JNLP client)
+-- war (unpacks JNLP client)
+-- ear (pack web)

During "mvn site" call, the "unpack" goal breaks in the way shown above.
I will try to create a test case for this.

Sorry for the noise, it seems that the unpack was triggered in some ways by the Cobertura plugin. I thought that a workaround was to put the dependency to unpack as a provided dependency, however it does not work (I made some mistakes before).

Added test case to reproduce the problem. Cobertura plugin triggers the WAR build that fails to unpack a dependency.

Added testcase that uses Surefire report instead of Cobertura. So this seems not to be a Cobertura plugin related bug.
Probably, it's the way the build is triggered that make it fail.
However, the workaround is doing an "mvn package" before doing "mvn site". It seems that this way the WAR is not rebuilt and, therefore, the "unpack" goal is not called.

I've reproduced this using attached surefire test case. [1] is relevant build log with error when running just mvn site.

With this command one runs site phase of site lifecycle to which by default maven-site-plugin site} goal is bound to. Site plugin site goal runs {{test phase of default lifecycle. package phase, to which assembly of jar module zip archive with bin classifier is bound, will not be triggered by this test phase execution, but process-resources in war module, to which unpacking of that bin/zip is bound, will be triggered. IMO it's wrong that dependency plugin manages to resolve jar module from reactor - it should try to resolve one with bin classifier (and not main jar module), and in that case I'd expect build to fail with missing dependency reported since jar module with bin classifier creation has not been triggered and thus it's not attached to the build.

It's strange to me also that if you run "mvn package" as one build, and then "mvn site" as separate build that dependency plugin in "site" build will be able to resolve jar module bin classifier artifact and unpack it even though it's not installed on any repository nor is it in reactor of "site" build. Looks like a bug too, again related to resolving dependencies.

[1] build log

[INFO] ------------------------------------------------------------------------
[INFO] Building MDEP-98 test case - WAR 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-site-plugin:3.0:site (default-site) @ mdep98-testcase-web ---
[INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.4
[INFO] configuring report plugin org.apache.maven.plugins:maven-surefire-report-plugin:2.10
[INFO]
[INFO] >>> maven-surefire-report-plugin:2.10:report-only (report:report-only) @ mdep98-testcase-web >>>
[INFO]
[INFO] <<< maven-surefire-report-plugin:2.10:report-only (report:report-only) @ mdep98-testcase-web <<<
[INFO]
[INFO] >>> maven-surefire-report-plugin:2.10:report (report:report) @ mdep98-testcase-web >>>
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ mdep98-testcase-web ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web ---
[INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip
[INFO] Unpacking D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-jar\target\classes to
  D:\temp\mdep89\mdep98-testcase-parent\mdep98-testcase-web\target\mdep98-testcase-web-1.0.0-SNAPSHOT\webstart
   with includes null and excludes:null
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:260)
        at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122)
        at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeForkedExecutions(DefaultLifecycleExecutor.java:175
)
        at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildReportPlugin(DefaultMavenReportExecutor.java:
282)
        at org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports(DefaultMavenReportExecutor.java:
148)
        at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getReports(AbstractSiteRenderingMojo.java:240)

Stevo, just a comment about the last sentence about "mvn package" and "mvn site".
I don't think that unpack goal is run and it succeeds, but I think that the report executor notices that the build has been already done, and then it does not retry to build it. So it succeeds simply because the unpack does not run.

In "site" build after "package" build maven-dependency-plugin reports that classes were already unpacked:

[INFO] --- maven-dependency-plugin:2.1:unpack (default) @ mdep98-testcase-web ---
[INFO] Configured Artifact: foo.bar:mdep98-testcase-jar:bin:1.0.0-SNAPSHOT:zip
[INFO] classes already unpacked.

Whoops! Sorry Stevo you're right, thank you.

This is pretty simple to reproduce with mvn site.

What's the recommended workaround?

get ready for the 5 years anniversary of this bug !!!

Ok, seriously, what you guys need to get it fixed ?

My solution: stop using Maven.

There is some more activity on the duplicate MDEP-194. Can you try the patch there?

like MDEP-187, error message improved in r1368261
this doesn't fix the problem but at least makes it easier to track
notice that another corner case to take care is when the dependency to unpack has a classifier/specific packaging: we can't imagine the content before the artifact has been packaged

Any progress on this? This is a rather serious bug that seems to be causing a bit of trouble. As stated above, I would expect if it is a directory it should just be copied. Also there is a possible patch that has been mentioned, but nobody seems to be indicating it has been tried out.

As far as the comment about needing to do an install on the modules, that is not always a desirable thing to do. If you have multiple builds running on the same box with each of them installing, your build may end up getting the artifact published by the other build, not the one from this build. The only way to ensure you have the right contents is to use the artifact from the same workspace.

As a side-note, I updated to the latest version (2.5) and used the package goal and all seems to be working.

I had this issue also with sonar:sonar. There is a simple workaround which could be applicable for some other scenarios as well. The problem is unpack will attempt to use folder as its source only if package was not executed for this module as part of the build.

So in my case the workaround was to run "mvn package sonar:sonar" instead of "mvn sonar:sonar". The former does certain things twice so it's less effective, but when reactor detects package was performed, it will unpack dependencies from jar instead of going for the folder. Probably the workaround can be improved through explicit package execution.

For Sonar, the "official" workaround is to use the sonar.phase parameter, asking Sonar to run the build up to a certain phase:

mvn sonar:sonar -Dsonar.phase=package

This is probably quite similar to the previous comment, and of course it runs the tests twice.

(I must confess I sometimes move the goal that packages from the package phase to the process-test-classes phase, so that I only have to build up to that phase, avoiding the test phase. Shame on me...)