You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jörg Schaible <jo...@bpm-inspire.com> on 2017/02/07 09:07:30 UTC
Re: MNG-5567: Zips on classpath
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
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