You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Benedict <pb...@apache.org> on 2016/08/15 15:18:20 UTC
MNG-5567: Zips on classpath
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.
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.
Cheers,
Paul
Re: MNG-5567: Zips on classpath
Posted by Robert Scholte <rf...@apache.org>.
On Mon, 15 Aug 2016 17:59:14 +0200, Paul Benedict <pb...@apache.org>
wrote:
> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Paul Benedict <pb...@apache.org>.
Michael, Robert, and Christian, thank you all for your input. I found the
discussion very helpful and fruitful.
The issue for introducing a new scope for non-functional resources is here:
https://issues.apache.org/jira/browse/MNG-6080
I would like to take part in the development of this feature, if possible.
Please let me know anyway which I can help.
Cheers,
Paul
On Mon, Aug 15, 2016 at 2:12 PM, Paul Benedict <pb...@apache.org> wrote:
> This thread is about altering the implementation of MNG-5567. I am unsure
> why you think it's unrelated to the new scope; that is being proposed as
> the new implementation. If the new scope can be introduced in 3.4, then I
> think MNG-5567 should be too; otherwise rolled back.
>
> Cheers,
> Paul
>
> On Mon, Aug 15, 2016 at 1:16 PM, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2016-08-15 um 19:57 schrieb Paul Benedict:
>>
>>> I hear different opinions on how to move forward. Robert believes it's
>>> possible with MPLUGIN-305 (is that really the right ticket #?), but you
>>> have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
>>> cannot be introduced, then I would like MNG-5567 backed out until 4.0.
>>>
>>
>> MNG-5567 and a new scope are not related to each other. Just file an
>> issue to track this request. Maybe Christian is right and we could
>> introduce this in 3.4.
>>
>> Michael
>>
>>
>> Aug 15, 2016 at 11:53 AM, Michael Osipov <mi...@apache.org>
>>
>>> wrote:
>>>
>>> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>>>>
>>>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@apache.org>
>>>>> wrote:
>>>>>
>>>>>
>>>> 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".
>>>>>
>>>>>
>>>> While this sounds reasonable, I highly doubt that this will happen
>>>> before
>>>> Maven 4.0.
>>>>
>>>> You may want to raise an issue for this.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: MNG-5567: Zips on classpath
Posted by Paul Benedict <pb...@apache.org>.
This thread is about altering the implementation of MNG-5567. I am unsure
why you think it's unrelated to the new scope; that is being proposed as
the new implementation. If the new scope can be introduced in 3.4, then I
think MNG-5567 should be too; otherwise rolled back.
Cheers,
Paul
On Mon, Aug 15, 2016 at 1:16 PM, Michael Osipov <mi...@apache.org> wrote:
> Am 2016-08-15 um 19:57 schrieb Paul Benedict:
>
>> I hear different opinions on how to move forward. Robert believes it's
>> possible with MPLUGIN-305 (is that really the right ticket #?), but you
>> have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
>> cannot be introduced, then I would like MNG-5567 backed out until 4.0.
>>
>
> MNG-5567 and a new scope are not related to each other. Just file an issue
> to track this request. Maybe Christian is right and we could introduce this
> in 3.4.
>
> Michael
>
>
> Aug 15, 2016 at 11:53 AM, Michael Osipov <mi...@apache.org>
>
>> wrote:
>>
>> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>>>
>>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@apache.org>
>>>> wrote:
>>>>
>>>>
>>> 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".
>>>>
>>>>
>>> While this sounds reasonable, I highly doubt that this will happen before
>>> Maven 4.0.
>>>
>>> You may want to raise an issue for this.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-15 um 19:57 schrieb Paul Benedict:
> I hear different opinions on how to move forward. Robert believes it's
> possible with MPLUGIN-305 (is that really the right ticket #?), but you
> have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
> cannot be introduced, then I would like MNG-5567 backed out until 4.0.
MNG-5567 and a new scope are not related to each other. Just file an
issue to track this request. Maybe Christian is right and we could
introduce this in 3.4.
Michael
Aug 15, 2016 at 11:53 AM, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>>
>>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@apache.org>
>>> wrote:
>>>
>>
>> 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".
>>>
>>
>> While this sounds reasonable, I highly doubt that this will happen before
>> Maven 4.0.
>>
>> You may want to raise an issue for this.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-15 um 20:08 schrieb Christian Schulte:
> Am 08/15/16 um 19:57 schrieb Paul Benedict:
>> I hear different opinions on how to move forward. Robert believes it's
>> possible with MPLUGIN-305 (is that really the right ticket #?), but you
>> have doubts for the 3.x series. Which shall it be for 3.4?
>
> The 'import' scope was introduced in a patch release (2.0.9). I see no
> reason something like this cannot go into 3.4 (minor version increment
> already). Just my personal opinion, of course.
Probably not the stupidest idea after all. Maybe scope 'reactor'?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Christian Schulte <cs...@schulte.it>.
Am 08/15/16 um 19:57 schrieb Paul Benedict:
> I hear different opinions on how to move forward. Robert believes it's
> possible with MPLUGIN-305 (is that really the right ticket #?), but you
> have doubts for the 3.x series. Which shall it be for 3.4?
The 'import' scope was introduced in a patch release (2.0.9). I see no
reason something like this cannot go into 3.4 (minor version increment
already). Just my personal opinion, of course.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Robert Scholte <rf...@apache.org>.
My mistake: it's MPLUGIN-302, Dependency Annotation
On Mon, 15 Aug 2016 19:57:25 +0200, Paul Benedict <pb...@apache.org>
wrote:
> I hear different opinions on how to move forward. Robert believes it's
> possible with MPLUGIN-305 (is that really the right ticket #?), but you
> have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
> cannot be introduced, then I would like MNG-5567 backed out until 4.0.
>
> Cheers,
> Paul
>
> On Mon, Aug 15, 2016 at 11:53 AM, Michael Osipov <mi...@apache.org>
> wrote:
>
>> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>>
>>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@apache.org>
>>> wrote:
>>>
>>
>> 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".
>>>
>>
>> While this sounds reasonable, I highly doubt that this will happen
>> before
>> Maven 4.0.
>>
>> You may want to raise an issue for this.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Paul Benedict <pb...@apache.org>.
I hear different opinions on how to move forward. Robert believes it's
possible with MPLUGIN-305 (is that really the right ticket #?), but you
have doubts for the 3.x series. Which shall it be for 3.4? If a new scope
cannot be introduced, then I would like MNG-5567 backed out until 4.0.
Cheers,
Paul
On Mon, Aug 15, 2016 at 11:53 AM, Michael Osipov <mi...@apache.org>
wrote:
> Am 2016-08-15 um 17:59 schrieb Paul Benedict:
>
>> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@apache.org>
>> wrote:
>>
>
> 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".
>>
>
> While this sounds reasonable, I highly doubt that this will happen before
> Maven 4.0.
>
> You may want to raise an issue for this.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-15 um 17:59 schrieb Paul Benedict:
> On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@apache.org>
> wrote:
>> 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".
While this sounds reasonable, I highly doubt that this will happen
before Maven 4.0.
You may want to raise an issue for this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Paul Benedict <pb...@apache.org>.
On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov <mi...@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
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-02-09 um 21:30 schrieb Benson Margulies:
> How? When I declare a zip dependency on a non-reactor artifact, it is
> just <type>zip</type>. Packaging doesn't show up in <dependencies>, or
> is this what you are proposing?
https://issues.apache.org/jira/browse/MNG-1683
The ZIP would have its own POM and lifecycle. Roughly, drastically
reduced JAR lifecycle.
> On Thu, Feb 9, 2017 at 12:18 PM, Michael Osipov <mi...@apache.org> wrote:
>> Am 2017-02-09 um 21:10 schrieb Benson Margulies:
>>>
>>> -1 to zips on the classpath. We need to disentangle the java classpath
>>> from the general concept of 'module X depends on module Y'. I created
>>> quite a lot of code that uses zips as containers to pass files from
>>> one place to another, and would be horribly broken if their transitive
>>> dependencies started showing up.
>>
>>
>> This is because we finally need packaging zip. It would solve your problem.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Benson Margulies <bi...@gmail.com>.
How? When I declare a zip dependency on a non-reactor artifact, it is
just <type>zip</type>. Packaging doesn't show up in <dependencies>, or
is this what you are proposing?
On Thu, Feb 9, 2017 at 12:18 PM, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-02-09 um 21:10 schrieb Benson Margulies:
>>
>> -1 to zips on the classpath. We need to disentangle the java classpath
>> from the general concept of 'module X depends on module Y'. I created
>> quite a lot of code that uses zips as containers to pass files from
>> one place to another, and would be horribly broken if their transitive
>> dependencies started showing up.
>
>
> This is because we finally need packaging zip. It would solve your problem.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re: MNG-5567: Zips on classpath
Posted by Stian Soiland-Reyes <st...@apache.org>.
For data zips you might also be interested in my data-maven-plugin:
https://github.com/stain/data-maven-plugin
It creates a type>data.zip</type>
This can be used as a regular zip file or <dependency> on the class path,
as it always puts the data files under data/{artifactId}/ -- this gives a
reasonable separation for multiple data artifacts.
I tried to optimize it to avoid copying through target/classes as data
files could be larger than 2 GB, but there might be internal inefficiencies
still in the underlying zipfs support. (tar and BagIt might be a cleaner
format for data archives).
I had the same issue of transitive dependencies, as I had some data
artifacts made as a selection from a larger artifact. I had to use
<scope>provided</> to avoid transitivity, which feels a bit of cheating
semantically. <optional> is similarly cheeting, because it hints it might
be useful by downstream.
The problem is that the compile scope is assumed to also be the runtime
scope, which assumes a standard javac type build.
What I have often found is the need for a <scope>compile-only</scope>
dependency, which Maven does not provide. This is particularly the case for
OSGi repackaging, where people often do the mistake of listing the non-osgi
jars as compile dependency, thus depending on the resulting OSGi bundle
will inadvertently pull in duplicate dependencies that were only needed for
mvn package.
At the same time I want to have the option of <dependencies> from a data
artifact, both for other data artifacts (e.g. reference data or
vocabularies) and libraries (e.g. to help access the data). In a way
building, releasing and using data should not be too different from with
software, it just needs some extra help to start doing something useful.
I am not so sure about two (three!) different <type>zip</type>s. Perhaps
rather a generic <ignoreAll/> to avoid any transitives of a <dependency>?
On 10 Feb 2017 9:32 am, "Stephen Connolly" <st...@gmail.com>
wrote:
My vote is this:
For pre-5.0.0: the zip ship has sailed. We cannot change how a
<type>zip</type> affects the transitive dependencies. If we want to make it
easier to package zips I would suggest we create two different packagings:
<configuration>
<packaging>classpath-zip</packaging>
<type>classpath-zip</type>
<extension>zip</extension>
<language>java</language>
<addedToClasspath>true</addedToClasspath>
</configuration>
<configuration>
<packaging>resource-zip</packaging>
<type>resource-zip</type>
<extension>zip</extension>
<addedToClasspath>false</addedToClasspath>
</configuration>
This would let people build resource zips easily and classpath zips easily.
If they are available by default what we would get is
<dependency>
<artifactId>foo</artifactId>
<type>zip</type>
</dependency>
<dependency>
<artifactId>bar</artifactId>
<type>classpath-zip</type>
</dependency>
<dependency>
<artifactId>manchu</artifactId>
<type>resource-zip</type>
</dependency>
So the first dependency, foo, is specifying a type for which there is no
registered handler => will not be added to the classpath.
The second dependency, bar, is specifying classpath-zip as the type, so
maven will look for an artifact with the extension zip and add its
dependencies to the classpath
The third dependency, manchu, is specifying resource-zip as the type, so
maven again will look for a zip but not add it to the classpath.
The best bit is that Maven does not care what <packaging> we used when
building foo, bar or manchu. You get to retroactively declare them as
classpath or resource and we get a clean identification of dependencies
where we have not classified them yes.
A simpler version is to replace the type of `resource-zip` with `zip` on
the basis that it is just formalizing the existing usage and classpath
usage is expected to be rare, e.g.
<configuration>
<packaging>resource-zip</packaging>
<type>zip</type>
<extension>zip</extension>
<addedToClasspath>false</addedToClasspath>
</configuration>
That might confuse users but we could document it being clear that they
need to decide which form...
If we really expect classpath zips to be exceedingly rare, then we could
just to
<configuration>
<packaging>zip</packaging>
<type>zip</type>
<extension>zip</extension>
<addedToClasspath>false</addedToClasspath>
</configuration>
And leave the classpath-zip for ones that need to be on the classpath
For 5.0.0+: the PDTs provide a better solution as project declares the
dependency trees of each artifact
On 10 February 2017 at 08:25, Michael Osipov <19...@gmx.net> wrote:
> > Hi Michael,
> >
> > Michael Osipov wrote:
> >
> > > Am 2017-02-09 um 21:10 schrieb Benson Margulies:
> > >> -1 to zips on the classpath. We need to disentangle the java
classpath
> > >> from the general concept of 'module X depends on module Y'. I created
> > >> quite a lot of code that uses zips as containers to pass files from
> > >> one place to another, and would be horribly broken if their
transitive
> > >> dependencies started showing up.
> > >
> > > This is because we finally need packaging zip. It would solve your
> > > problem.
> >
> > Sorry, maybe I don't understand a concept here, but how does this solve
> the
> > problem for existing zips (with classifiers)? IMHO their packaging type
> is
> > also "zip" and if these zip files suddenly transport dependencies it
will
> > break existing projects.
>
> It won't, of course, solve the problem with pre-existing files, but give
> you
> a clean way to do things right with new files.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Re: MNG-5567: Zips on classpath
Posted by Stephen Connolly <st...@gmail.com>.
My vote is this:
For pre-5.0.0: the zip ship has sailed. We cannot change how a
<type>zip</type> affects the transitive dependencies. If we want to make it
easier to package zips I would suggest we create two different packagings:
<configuration>
<packaging>classpath-zip</packaging>
<type>classpath-zip</type>
<extension>zip</extension>
<language>java</language>
<addedToClasspath>true</addedToClasspath>
</configuration>
<configuration>
<packaging>resource-zip</packaging>
<type>resource-zip</type>
<extension>zip</extension>
<addedToClasspath>false</addedToClasspath>
</configuration>
This would let people build resource zips easily and classpath zips easily.
If they are available by default what we would get is
<dependency>
<artifactId>foo</artifactId>
<type>zip</type>
</dependency>
<dependency>
<artifactId>bar</artifactId>
<type>classpath-zip</type>
</dependency>
<dependency>
<artifactId>manchu</artifactId>
<type>resource-zip</type>
</dependency>
So the first dependency, foo, is specifying a type for which there is no
registered handler => will not be added to the classpath.
The second dependency, bar, is specifying classpath-zip as the type, so
maven will look for an artifact with the extension zip and add its
dependencies to the classpath
The third dependency, manchu, is specifying resource-zip as the type, so
maven again will look for a zip but not add it to the classpath.
The best bit is that Maven does not care what <packaging> we used when
building foo, bar or manchu. You get to retroactively declare them as
classpath or resource and we get a clean identification of dependencies
where we have not classified them yes.
A simpler version is to replace the type of `resource-zip` with `zip` on
the basis that it is just formalizing the existing usage and classpath
usage is expected to be rare, e.g.
<configuration>
<packaging>resource-zip</packaging>
<type>zip</type>
<extension>zip</extension>
<addedToClasspath>false</addedToClasspath>
</configuration>
That might confuse users but we could document it being clear that they
need to decide which form...
If we really expect classpath zips to be exceedingly rare, then we could
just to
<configuration>
<packaging>zip</packaging>
<type>zip</type>
<extension>zip</extension>
<addedToClasspath>false</addedToClasspath>
</configuration>
And leave the classpath-zip for ones that need to be on the classpath
For 5.0.0+: the PDTs provide a better solution as project declares the
dependency trees of each artifact
On 10 February 2017 at 08:25, Michael Osipov <19...@gmx.net> wrote:
> > Hi Michael,
> >
> > Michael Osipov wrote:
> >
> > > Am 2017-02-09 um 21:10 schrieb Benson Margulies:
> > >> -1 to zips on the classpath. We need to disentangle the java classpath
> > >> from the general concept of 'module X depends on module Y'. I created
> > >> quite a lot of code that uses zips as containers to pass files from
> > >> one place to another, and would be horribly broken if their transitive
> > >> dependencies started showing up.
> > >
> > > This is because we finally need packaging zip. It would solve your
> > > problem.
> >
> > Sorry, maybe I don't understand a concept here, but how does this solve
> the
> > problem for existing zips (with classifiers)? IMHO their packaging type
> is
> > also "zip" and if these zip files suddenly transport dependencies it will
> > break existing projects.
>
> It won't, of course, solve the problem with pre-existing files, but give
> you
> a clean way to do things right with new files.
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <19...@gmx.net>.
> Hi Michael,
>
> Michael Osipov wrote:
>
> > Am 2017-02-09 um 21:10 schrieb Benson Margulies:
> >> -1 to zips on the classpath. We need to disentangle the java classpath
> >> from the general concept of 'module X depends on module Y'. I created
> >> quite a lot of code that uses zips as containers to pass files from
> >> one place to another, and would be horribly broken if their transitive
> >> dependencies started showing up.
> >
> > This is because we finally need packaging zip. It would solve your
> > problem.
>
> Sorry, maybe I don't understand a concept here, but how does this solve the
> problem for existing zips (with classifiers)? IMHO their packaging type is
> also "zip" and if these zip files suddenly transport dependencies it will
> break existing projects.
It won't, of course, solve the problem with pre-existing files, but give you
a clean way to do things right with new files.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Hi Michael,
Michael Osipov wrote:
> Am 2017-02-09 um 21:10 schrieb Benson Margulies:
>> -1 to zips on the classpath. We need to disentangle the java classpath
>> from the general concept of 'module X depends on module Y'. I created
>> quite a lot of code that uses zips as containers to pass files from
>> one place to another, and would be horribly broken if their transitive
>> dependencies started showing up.
>
> This is because we finally need packaging zip. It would solve your
> problem.
Sorry, maybe I don't understand a concept here, but how does this solve the
problem for existing zips (with classifiers)? IMHO their packaging type is
also "zip" and if these zip files suddenly transport dependencies it will
break existing projects.
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-02-09 um 21:10 schrieb Benson Margulies:
> -1 to zips on the classpath. We need to disentangle the java classpath
> from the general concept of 'module X depends on module Y'. I created
> quite a lot of code that uses zips as containers to pass files from
> one place to another, and would be horribly broken if their transitive
> dependencies started showing up.
This is because we finally need packaging zip. It would solve your problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Benson Margulies <bi...@gmail.com>.
-1 to zips on the classpath. We need to disentangle the java classpath
from the general concept of 'module X depends on module Y'. I created
quite a lot of code that uses zips as containers to pass files from
one place to another, and would be horribly broken if their transitive
dependencies started showing up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-02-09 um 13:31 schrieb Robert Scholte:
> While thinking this all over, it is kind of strange that a type can
> decide for itself how it should be used.
> I thought about moving this info to the proper packaging-plugin, but
> that's not correct either, because e.g war and jar need to have the same
> logic.
> So in this case it is the maven-compiler-plugin which exactly knows
> which types are allowed on the classpath.
> This also matches with my idea that anything related to the Java
> langauge (e.g. <addedToClasspath/> ) does not belong in Maven Core.
This would be long-term only. For now, we need to solve this somehow
manageable.
> On Thu, 09 Feb 2017 13:21:56 +0100, Michael Osipov <19...@gmx.net>
> wrote:
>
>>> Now a ZIP packaging could do something different... we could have a
>>> `classpath-zip` packaging with the extension type `zip` so then if
>>> you go
>>> `<type>classpath-zip</type>` then Maven would know to look for a zip but
>>> add it on the classpath.
>> This looks overengineered to me. n types of ZIPs? We don't have this
>> for JAR either.
>>
>>
>>> On 9 February 2017 at 10:26, Michael Osipov <19...@gmx.net> wrote:
>>>
>>> > Why not 4.0.0? I think this must come in tandem with Packaging zip
>>> finally.
>>> >
>>> > > I don't see any compelling reason to add zips to the classpath now.
>>> > >
>>> > > We should have maybe done it from the start, but I don't see that
>>> we can
>>> > do
>>> > > it now before 5.0.0
>>> > >
>>> > > (And I am not even seeing a compelling reason to add it then...
>>> just it
>>> > > won't be as problematic)
>>> > >
>>> > > On Wed 8 Feb 2017 at 20:11, Michael Osipov <mi...@apache.org>
>>> wrote:
>>> > >
>>> > > > Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
>>> > > > > Hi,
>>> > > > >
>>> > > > > there's currently a discussion in JIRA regarding MNG-5576
>>> (Zips on
>>> > > > classpth)
>>> > > > > and Michael Osipov suggested to bring the discussion to the
>>> dev list.
>>> > > > > Actually this already happened once last August:
>>> > > > >
>>> > > > > Paul Benedict wrote:
>>> > > > >
>>> > > > >> 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.
>>> > > > >>
>>> > > > >> 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.
>>> > > > >
>>> > > > > my concern is also (b), because it is today quite common to
>>> use the
>>> > > > assembly
>>> > > > > plugin to create attached artficats with additional resources
>>> > required
>>> > > > later
>>> > > > > elsewhere (SQL scripts, WSDLs and their schema files, start
>>> scripts,
>>> > > > ...).
>>> > > > > None of this stuff is meant to be on classpath.
>>> > > > >
>>> > > > > On top, all these artifacts will suddenly inject transitive
>>> > dependencies
>>> > > > > whereever they are referenced - just by using a new Maven
>>> version.
>>> > We'll
>>> > > > > face bloated WARs and EARs with stuff not belonging there for
>>> > *existing*
>>> > > > > projects. IMHO MNG-4467 has much more unwanted side-effects
>>> in the
>>> > curent
>>> > > > > ecosystem compared to the support of one or two projects that
>>> deliver
>>> > > > their
>>> > > > > Java archives as ZIP files.
>>> > > >
>>> > > > Seems like there no opinion on that. What now?
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> ---------------------------------------------------------------------
>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>> > > >
>>> > > > --
>>> > > Sent from my phone
>>> > >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re: Re: MNG-5567: Zips on classpath
Posted by Robert Scholte <rf...@apache.org>.
While thinking this all over, it is kind of strange that a type can decide
for itself how it should be used.
I thought about moving this info to the proper packaging-plugin, but
that's not correct either, because e.g war and jar need to have the same
logic.
So in this case it is the maven-compiler-plugin which exactly knows which
types are allowed on the classpath.
This also matches with my idea that anything related to the Java langauge
(e.g. <addedToClasspath/> ) does not belong in Maven Core.
Robert
On Thu, 09 Feb 2017 13:21:56 +0100, Michael Osipov <19...@gmx.net>
wrote:
>> Now a ZIP packaging could do something different... we could have a
>> `classpath-zip` packaging with the extension type `zip` so then if you
>> go
>> `<type>classpath-zip</type>` then Maven would know to look for a zip but
>> add it on the classpath.
> This looks overengineered to me. n types of ZIPs? We don't have this for
> JAR either.
>
>
>> On 9 February 2017 at 10:26, Michael Osipov <19...@gmx.net> wrote:
>>
>> > Why not 4.0.0? I think this must come in tandem with Packaging zip
>> finally.
>> >
>> > > I don't see any compelling reason to add zips to the classpath now.
>> > >
>> > > We should have maybe done it from the start, but I don't see that
>> we can
>> > do
>> > > it now before 5.0.0
>> > >
>> > > (And I am not even seeing a compelling reason to add it then...
>> just it
>> > > won't be as problematic)
>> > >
>> > > On Wed 8 Feb 2017 at 20:11, Michael Osipov <mi...@apache.org>
>> wrote:
>> > >
>> > > > Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
>> > > > > Hi,
>> > > > >
>> > > > > there's currently a discussion in JIRA regarding MNG-5576 (Zips
>> on
>> > > > classpth)
>> > > > > and Michael Osipov suggested to bring the discussion to the dev
>> list.
>> > > > > Actually this already happened once last August:
>> > > > >
>> > > > > Paul Benedict wrote:
>> > > > >
>> > > > >> 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.
>> > > > >>
>> > > > >> 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.
>> > > > >
>> > > > > my concern is also (b), because it is today quite common to use
>> the
>> > > > assembly
>> > > > > plugin to create attached artficats with additional resources
>> > required
>> > > > later
>> > > > > elsewhere (SQL scripts, WSDLs and their schema files, start
>> scripts,
>> > > > ...).
>> > > > > None of this stuff is meant to be on classpath.
>> > > > >
>> > > > > On top, all these artifacts will suddenly inject transitive
>> > dependencies
>> > > > > whereever they are referenced - just by using a new Maven
>> version.
>> > We'll
>> > > > > face bloated WARs and EARs with stuff not belonging there for
>> > *existing*
>> > > > > projects. IMHO MNG-4467 has much more unwanted side-effects in
>> the
>> > curent
>> > > > > ecosystem compared to the support of one or two projects that
>> deliver
>> > > > their
>> > > > > Java archives as ZIP files.
>> > > >
>> > > > Seems like there no opinion on that. What now?
>> > > >
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >
>> > > > --
>> > > Sent from my phone
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re: Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <19...@gmx.net>.
> Now a ZIP packaging could do something different... we could have a
> `classpath-zip` packaging with the extension type `zip` so then if you go
> `<type>classpath-zip</type>` then Maven would know to look for a zip but
> add it on the classpath.
This looks overengineered to me. n types of ZIPs? We don't have this for JAR either.
> On 9 February 2017 at 10:26, Michael Osipov <19...@gmx.net> wrote:
>
> > Why not 4.0.0? I think this must come in tandem with Packaging zip finally.
> >
> > > I don't see any compelling reason to add zips to the classpath now.
> > >
> > > We should have maybe done it from the start, but I don't see that we can
> > do
> > > it now before 5.0.0
> > >
> > > (And I am not even seeing a compelling reason to add it then... just it
> > > won't be as problematic)
> > >
> > > On Wed 8 Feb 2017 at 20:11, Michael Osipov <mi...@apache.org> wrote:
> > >
> > > > Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
> > > > > Hi,
> > > > >
> > > > > there's currently a discussion in JIRA regarding MNG-5576 (Zips on
> > > > classpth)
> > > > > and Michael Osipov suggested to bring the discussion to the dev list.
> > > > > Actually this already happened once last August:
> > > > >
> > > > > Paul Benedict wrote:
> > > > >
> > > > >> 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.
> > > > >>
> > > > >> 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.
> > > > >
> > > > > my concern is also (b), because it is today quite common to use the
> > > > assembly
> > > > > plugin to create attached artficats with additional resources
> > required
> > > > later
> > > > > elsewhere (SQL scripts, WSDLs and their schema files, start scripts,
> > > > ...).
> > > > > None of this stuff is meant to be on classpath.
> > > > >
> > > > > On top, all these artifacts will suddenly inject transitive
> > dependencies
> > > > > whereever they are referenced - just by using a new Maven version.
> > We'll
> > > > > face bloated WARs and EARs with stuff not belonging there for
> > *existing*
> > > > > projects. IMHO MNG-4467 has much more unwanted side-effects in the
> > curent
> > > > > ecosystem compared to the support of one or two projects that deliver
> > > > their
> > > > > Java archives as ZIP files.
> > > >
> > > > Seems like there no opinion on that. What now?
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > > --
> > > Sent from my phone
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Re: MNG-5567: Zips on classpath
Posted by Stephen Connolly <st...@gmail.com>.
Because if it lands in 4.0.0 then it will break existing POMs that have
relied on ZIP files not being added to the classpath.
Only when we get the PDT in 5.0.0 can we safely add them to the classpath...
Now a ZIP packaging could do something different... we could have a
`classpath-zip` packaging with the extension type `zip` so then if you go
`<type>classpath-zip</type>` then Maven would know to look for a zip but
add it on the classpath.
If you want to do that, :+1:
On 9 February 2017 at 10:26, Michael Osipov <19...@gmx.net> wrote:
> Why not 4.0.0? I think this must come in tandem with Packaging zip finally.
>
> > I don't see any compelling reason to add zips to the classpath now.
> >
> > We should have maybe done it from the start, but I don't see that we can
> do
> > it now before 5.0.0
> >
> > (And I am not even seeing a compelling reason to add it then... just it
> > won't be as problematic)
> >
> > On Wed 8 Feb 2017 at 20:11, Michael Osipov <mi...@apache.org> wrote:
> >
> > > Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
> > > > Hi,
> > > >
> > > > there's currently a discussion in JIRA regarding MNG-5576 (Zips on
> > > classpth)
> > > > and Michael Osipov suggested to bring the discussion to the dev list.
> > > > Actually this already happened once last August:
> > > >
> > > > Paul Benedict wrote:
> > > >
> > > >> 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.
> > > >>
> > > >> 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.
> > > >
> > > > my concern is also (b), because it is today quite common to use the
> > > assembly
> > > > plugin to create attached artficats with additional resources
> required
> > > later
> > > > elsewhere (SQL scripts, WSDLs and their schema files, start scripts,
> > > ...).
> > > > None of this stuff is meant to be on classpath.
> > > >
> > > > On top, all these artifacts will suddenly inject transitive
> dependencies
> > > > whereever they are referenced - just by using a new Maven version.
> We'll
> > > > face bloated WARs and EARs with stuff not belonging there for
> *existing*
> > > > projects. IMHO MNG-4467 has much more unwanted side-effects in the
> curent
> > > > ecosystem compared to the support of one or two projects that deliver
> > > their
> > > > Java archives as ZIP files.
> > >
> > > Seems like there no opinion on that. What now?
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <19...@gmx.net>.
Why not 4.0.0? I think this must come in tandem with Packaging zip finally.
> I don't see any compelling reason to add zips to the classpath now.
>
> We should have maybe done it from the start, but I don't see that we can do
> it now before 5.0.0
>
> (And I am not even seeing a compelling reason to add it then... just it
> won't be as problematic)
>
> On Wed 8 Feb 2017 at 20:11, Michael Osipov <mi...@apache.org> wrote:
>
> > Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
> > > Hi,
> > >
> > > there's currently a discussion in JIRA regarding MNG-5576 (Zips on
> > classpth)
> > > and Michael Osipov suggested to bring the discussion to the dev list.
> > > Actually this already happened once last August:
> > >
> > > Paul Benedict wrote:
> > >
> > >> 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.
> > >>
> > >> 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.
> > >
> > > my concern is also (b), because it is today quite common to use the
> > assembly
> > > plugin to create attached artficats with additional resources required
> > later
> > > elsewhere (SQL scripts, WSDLs and their schema files, start scripts,
> > ...).
> > > None of this stuff is meant to be on classpath.
> > >
> > > On top, all these artifacts will suddenly inject transitive dependencies
> > > whereever they are referenced - just by using a new Maven version. We'll
> > > face bloated WARs and EARs with stuff not belonging there for *existing*
> > > projects. IMHO MNG-4467 has much more unwanted side-effects in the curent
> > > ecosystem compared to the support of one or two projects that deliver
> > their
> > > Java archives as ZIP files.
> >
> > Seems like there no opinion on that. What now?
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> Sent from my phone
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Stephen Connolly <st...@gmail.com>.
I don't see any compelling reason to add zips to the classpath now.
We should have maybe done it from the start, but I don't see that we can do
it now before 5.0.0
(And I am not even seeing a compelling reason to add it then... just it
won't be as problematic)
On Wed 8 Feb 2017 at 20:11, Michael Osipov <mi...@apache.org> wrote:
> Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
> > Hi,
> >
> > there's currently a discussion in JIRA regarding MNG-5576 (Zips on
> classpth)
> > and Michael Osipov suggested to bring the discussion to the dev list.
> > Actually this already happened once last August:
> >
> > Paul Benedict wrote:
> >
> >> 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.
> >>
> >> 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.
> >
> > my concern is also (b), because it is today quite common to use the
> assembly
> > plugin to create attached artficats with additional resources required
> later
> > elsewhere (SQL scripts, WSDLs and their schema files, start scripts,
> ...).
> > None of this stuff is meant to be on classpath.
> >
> > On top, all these artifacts will suddenly inject transitive dependencies
> > whereever they are referenced - just by using a new Maven version. We'll
> > face bloated WARs and EARs with stuff not belonging there for *existing*
> > projects. IMHO MNG-4467 has much more unwanted side-effects in the curent
> > ecosystem compared to the support of one or two projects that deliver
> their
> > Java archives as ZIP files.
>
> Seems like there no opinion on that. What now?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: MNG-5567: Zips on classpath
Posted by Michael Osipov <mi...@apache.org>.
Am 2017-02-07 um 10:07 schrieb Jörg Schaible:
> Hi,
>
> there's currently a discussion in JIRA regarding MNG-5576 (Zips on classpth)
> and Michael Osipov suggested to bring the discussion to the dev list.
> Actually this already happened once last August:
>
> Paul Benedict wrote:
>
>> 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.
>>
>> 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.
>
> my concern is also (b), because it is today quite common to use the assembly
> plugin to create attached artficats with additional resources required later
> elsewhere (SQL scripts, WSDLs and their schema files, start scripts, ...).
> None of this stuff is meant to be on classpath.
>
> On top, all these artifacts will suddenly inject transitive dependencies
> whereever they are referenced - just by using a new Maven version. We'll
> face bloated WARs and EARs with stuff not belonging there for *existing*
> projects. IMHO MNG-4467 has much more unwanted side-effects in the curent
> ecosystem compared to the support of one or two projects that deliver their
> Java archives as ZIP files.
Seems like there no opinion on that. What now?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MNG-5567: Zips on classpath
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Hi,
there's currently a discussion in JIRA regarding MNG-5576 (Zips on classpth)
and Michael Osipov suggested to bring the discussion to the dev list.
Actually this already happened once last August:
Paul Benedict wrote:
> 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.
>
> 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.
my concern is also (b), because it is today quite common to use the assembly
plugin to create attached artficats with additional resources required later
elsewhere (SQL scripts, WSDLs and their schema files, start scripts, ...).
None of this stuff is meant to be on classpath.
On top, all these artifacts will suddenly inject transitive dependencies
whereever they are referenced - just by using a new Maven version. We'll
face bloated WARs and EARs with stuff not belonging there for *existing*
projects. IMHO MNG-4467 has much more unwanted side-effects in the curent
ecosystem compared to the support of one or two projects that deliver their
Java archives as ZIP files.
Cheers,
J�rg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org