On Mon, 15 Aug 2016 17:59:14 +0200, Paul Benedict <pbened...@apache.org>
wrote:
On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <micha...@apache.org>
wrote:
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.
Yes, JARs are ZIPs with a different name, but not every ZIP is JAR. That
was the point I was trying to get across. Just because a Java project
employs ZIP files, it doesn't mean the ZIP is meant to be on the
classpath.
To be clear regarding my personal experience in using ZIPs, I am not
abusing JARs as resource containers: neither as a .jar file extension nor
"jar" Maven project type. I agree that's an abuse and have always avoided
it.
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?
I propose introducing a new scope. All the scopes dictate when a
dependency
makes it onto the classpath. In the case of a pure non-classpath resource
container, it never needs be on the classpath, but it does need to remain
available in the reactor. No current scope fits this need. If I may
propose
the new scope name, I would call it "asset".
Furthermore, I would give "zip" types this new "asset" scope as the
default. If anyone wants to add such a dependency to the classpath, they
should specify the appropriate scope. The benefit here is that (1) people
who are currently using "zip" (custom handlers?) wouldn't get their
classpath upended by new behavior and (2) explicitly adding a "zip" to
the
classpath requires them to think about what scope they desire.
Cheers,
Paul
Hi,
a scope is indeed the right way to control this. But that also means that
plugins must be able to understand either general or their own scopes.
I've had a look at the ArtifactHandler and was wondering if the
implementation is correct and you kind of confirms this.
The DefaultArtifactHandler has the field "addToClasspath". First of all:
classpaths are too close related to Java, the DefaultArtifactHandler
shouldn't care about this. But it also claims that certain types should
always be handled the same way. IMO it should be the scope which should
control these kind of things.
It looks like you're both referring to the maven-war-plugin where a zip
has a different purpose.
With MPLUGIN-305 it should be possible to give the zip a different scope,
so it doesn't end up on the classpath, but that it can be used for the
war-file.
thanks,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
