Re: MNG-5567: Zips on classpath

[Michael Osipov]

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 zip. Packaging doesn't show up in , 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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



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





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

Re: MNG-5567: Zips on classpath

[Benson Margulies]

How? When I declare a zip dependency on a non-reactor artifact, it is
just zip. Packaging doesn't show up in , or
is this what you are proposing?

On Thu, Feb 9, 2017 at 12:18 PM, 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.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: MNG-5567: Zips on classpath

[Michael Osipov]

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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5567: Zips on classpath

[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.

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

Re: MNG-5567: Zips on classpath

[Michael Osipov]

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.  ) 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 <1983-01...@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
`classpath-zip` 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 <1983-01...@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 
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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>



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

Re: Re: Re: MNG-5567: Zips on classpath

[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.  ) does not belong in Maven Core.


Robert

On Thu, 09 Feb 2017 13:21:56 +0100, Michael Osipov <1983-01...@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

`classpath-zip` 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 <1983-01...@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   
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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>



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

Re: Re: Re: MNG-5567: Zips on classpath

[Michael Osipov]

> 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
> `classpath-zip` 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 <1983-01...@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  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-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > --
> > > Sent from my phone
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

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

Re: I think we are ready for 3.5.0-alpha-1

[Stephen Connolly]

I have added some comments on the integration tests:
https://github.com/apache/maven-integration-testing/commit/f9c0d641ae362ff59c76bc7eb670c8214917f0c3

On 9 February 2017 at 11:28, Christian Schulte  wrote:

> Am 02/08/17 um 21:01 schrieb Stephen Connolly:
> > I think all the important stuff is merged. I'll take a final review
> through
> > and then cut alpha-1
> >
> > We can still add stuff if necessary for an alpha-2 but I'd much prefer to
> > focus that on shaking out bugs.
> >
> > Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
> > which point it should only be serious bug fixes)
> >
> > Then we give the beta some soak and cut the release
> >
> > I toyed with spinning RCs but I'm thinking alpha and beta are better
> terms
> >
> > Thoughts?
> >
>
> Can you please wait for MNG-2199. See the
>
> [IT] MNG-2199 - Take 2
>
> thread. The 72h will have passed in a few hours. I'll merge it then.
>
> Regards,
> --
> Christian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Re: MNG-5567: Zips on classpath

[Stephen Connolly]

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
`classpath-zip` 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 <1983-01...@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  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-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > --
> > Sent from my phone
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: I think we are ready for 3.5.0-alpha-1

[Christian Schulte]

Am 02/08/17 um 21:01 schrieb Stephen Connolly:
> I think all the important stuff is merged. I'll take a final review through
> and then cut alpha-1
> 
> We can still add stuff if necessary for an alpha-2 but I'd much prefer to
> focus that on shaking out bugs.
> 
> Ideally we do at most 3 alpha's before soft-code-freeze and a beta (at
> which point it should only be serious bug fixes)
> 
> Then we give the beta some soak and cut the release
> 
> I toyed with spinning RCs but I'm thinking alpha and beta are better terms
> 
> Thoughts?
> 

Can you please wait for MNG-2199. See the

[IT] MNG-2199 - Take 2

thread. The 72h will have passed in a few hours. I'll merge it then.

Regards,
-- 
Christian


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