Re: Re: MNG-5567: Zips on classpath

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 This can be used as a regular zip file or on the class path, as it always puts the data files under data/{artifactId}/ -- this gives a reasonable separation

Re: Re: MNG-5567: Zips on classpath

My vote is this: For pre-5.0.0: the zip ship has sailed. We cannot change how a zip affects the transitive dependencies. If we want to make it easier to package zips I would suggest we create two different packagings: classpath-zip classpath-zip zip

Re: Re: MNG-5567: Zips on classpath

> 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

Re: MNG-5567: Zips on classpath

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

Re: MNG-5567: Zips on classpath

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.

Re: MNG-5567: Zips on classpath

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

Re: MNG-5567: Zips on classpath

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

Re: MNG-5567: Zips on classpath

-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

Re: MNG-5567: Zips on classpath

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

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

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

Re: Re: Re: MNG-5567: Zips on 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. This looks overengineered to me. n types of ZIPs? We don't have

Re: Re: MNG-5567: Zips on classpath

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

Re: MNG-5567: Zips on classpath

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

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

Re: MNG-5567: Zips on classpath

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,

Re: MNG-5567: Zips on classpath

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,

Re: MNG-5567: Zips on classpath

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

Re: MNG-5567: Zips on classpath

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?

Re: MNG-5567: Zips on classpath

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

Re: MNG-5567: Zips on classpath

My mistake: it's MPLUGIN-302, Dependency Annotation On Mon, 15 Aug 2016 19:57:25 +0200, Paul Benedict 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

Re: MNG-5567: Zips on classpath

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,

Re: MNG-5567: Zips on classpath

Am 2016-08-15 um 17:59 schrieb Paul Benedict: On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov 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

Re: MNG-5567: Zips on classpath

On Mon, 15 Aug 2016 17:59:14 +0200, Paul Benedict wrote: On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov 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

Re: MNG-5567: Zips on classpath

On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov 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

Re: MNG-5567: Zips on classpath

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

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