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
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
> 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 containe
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-com
> 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
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
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 reaso
