When running a Maven build in eclipse using the m2eclipse tooling for a project that is configured for the Maven Shade Plugin, the build fails with the following error message:
Failed to execute goal org.apache.maven.plugins:maven-shade-plugin:2.4.3:shade (default) on project xxx: Error creating shaded jar: /.../project/target/classes (Is a directory) -> [Help 1]
I tried different versions of the Shade plugin and tried with different Java versions (6,7,8). All lead to the same error.
The solution for this question provides a workaround: The error only occurs if the option
Resolve Workspace Artifacts is selected. If this option is not selected, the build runs fine.
(However, this does not solve the problem since it is often very useful to build projects with enabled workspace resolution).
it is often very useful to build projects with enabled workspace resolution
I used to think the same... Obviously, it was pretty useful to be able to build project right from another project located in the current workspace. However, I quickly entered a nightmare with Eclipse, m2eclipse and Maven.
On one hand, Maven is supposed to find the project dependencies in a repository (local, central ...). On the other hand, m2eclipse "lures" Maven making it believe that a project located in the Eclipse workspace is a dependency in a well known Maven place (ie a repository).
This m2eclipse magic works great in some cases but in others... it just plainly fails (maven shade plugin is an example). Did you also notice that the option
Resolve Workspace Artifacts is not activated by default?
To escape the nigthmare, I found it useful to <strong>always</strong> fetch my projects dependencies from a repository. If my project A depends on another project B in my workspace, I just install B in the local repository (Right click on the project B,
Run as >
Maven install. That's all).
I can see three advantages with this workaround:
<li>No more nightmares</li>
<li>No m2eclipse magic involved</li>
<li>Full standard and conventional Maven way honored</li>
You can see this approach as a little freedom eater. If you still really want to go with the nifty option
Resolve Workspace Artifacts, send an issue to the m2eclipse team. Don't forget to prepare a sample project reproducing the problem.