Am 2016-08-15 um 17:18 schrieb Paul Benedict:
I would like to reopen MNG-5567 because I find the solution incomplete. As
the ticket stands today, any "zip" listed as a dependency will get put on
the classpath. The rationale behind that decision was:

(a) the classpath supports "zip" extensions
(b) there is apparently no harm in automatically putting everything "zip"
on the classpath
(c) there is no apparent reason to opt-out

I have an issue with (b) and (c). Here's why:

First, it violates the principle that developers should control what goes
on the classpath. I really can't believe Maven would wrestle this control
away. The assumption that every "zip" is meant to be on the classpath is
erroneous. This is not the case and Maven shouldn't automatically assume
it. Even if Maven was to assume it, the lack of opt-in behavior gives no
escape hatch.

Second, for projects that I personally deal with, these "zip" artifacts are
nothing but shared front-end web resources. These are not meant to on the
class path. The dependencies are there so other goals can unpack them
during the build and place them in the context root.

JARs are ZIPs with a different name, no less but a bit more. java(1) treats ZIP files as first-class citizens. We have taken away to option previously. People, including me, have abused JARs as resource containers (JS, images, css) to have them on the classpath with the entire, convoluted lifecycle JAR has.

Control of the classpath is the dependency list itself, isn't it?
There is opt-in/-out att all for any kind of dependency.

Third, it's possible a "zip" non-classpath resource could conflict with a
same named resource in the classpath. I haven't had to be concerned with
this (yet), but I will be on the lookout if MNG-5567 doesn't change.

I conflict in resources names can also happen with JARs and you have no control of it at all as of today.

How would you try to solve the problem?

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to