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" <[email protected]>
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 <[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]
>
>
