The third party plugin does not expect anything from the classpath as it is a
non-Java Maven plugin. Imagine this case: The ZIP (hypothetically) contains
SVG, the third party plugin renders into PDF, the PDF goes into the WAR as a
resource. Again, just hypothetically. Just ignore WHY the ZIP is
It is a dependency because it shall be built with -am if this project is built,
and it is consumed by this project using third party plugins. But it simply is
not consumed by the Java toolchain. This has nothing to do with the plugin. The
WAR produced here is built from Java source compiled to
That might work, but my intention is not to play with arbitrary experimental
PRs, but is to find a consensus, what such a future feature should look like to
get it accepted by the Maven team. Is that specific PR agreed to get adopted to
Maven 4? IIUC this PR stops adding ANY zips tot he
I think the biggest problem actually ist hat Maven once was build with Java in
mind, then developed to a cross-platform tool. Just because a ZIP is a ZIP does
not tell us to put ALL zips on the classpath. Hence what we need is either a
generic exclusion mechanism or a generic inclusion
Thanks for the quick tip.
While it might solve the actual problem I did have this morning, it is neither
a clean nor a general solution for everybody and for always, as it still
implies that all ZIPs shall go in the Java classpath unless custom-packaged.
Which means, possibly repackage rather
