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 <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
>
