Rob,
Thanks for pushing this along.
On 24/01/13 11:36, Rob Vesse wrote:
Per previous discussions for 2.10.0 release I have been experimenting
with maven a little and propose the following new maven module:
jena–libs
The naming is hard because we then have such a commitment to it.
At one time delivery artifacts were suggested to be apache-jena* and
jena-* development units. (Fuseki could/should become several modules and
have a delivery of apache-jena-fuseki.)
We already have apache-jena the download.
Version 1:
apache-jena -- download
apache-jena-libs -- maven integration artifact
Version 2:
apache-jena-system -- download
apache-jena -- maven integration artifact
Version 3:
apache-jena -- download
jena-libs -- maven integration artifact
I don't have a strong opinion; version 1 seems a little better (today).
This is a POM only module which serves as a convenience artifact,
specifying this artifact would pull in the standard Jena libraries –
Core, IRI, ARQ, TDB and SDB
Not SDB - we don't do a coordinated release of SDB with the Core, IRI,
ARQ, TDB set so it can be out-of-step with the rest.
Does this address what we are trying to do? If so I can go ahead and
commit this so we can play around with this.
+1 -- go for it
Rob
ps. I also wonder whether it might be worth adding the following
though I am less keen on this:
jena–libs-onejar
This is a JAR module which again serves as a convenience artifact,
this would use the maven shade plugin to build a single uber jar from
the jena-libs module. The intention is to provide a convenience
binary for those who don't use dependency management systems like
maven. They can download and add a single JAR to the class path and
not have to worry about ensuring they have the right dependencies.
This may be nice to have but I don't know whether we should encourage
this, having uber JARs can also cause problems since it can hide the
fact that you have multiple versions of a dependency on your class
path from easy inspection.
For people using maven, the common artifact is the important thing.
For people using the download, the non-jena jars also need to be included.
Including them in the uber jar is asking for confusion (use the fuseki
jar!), otherwise a set of jars has to be included anyway so rolling up jena
is only a small step.
So I don't see this as critical.
A command jar might be worth thinking about - have a apache-jena-cmds
which the command line tools packages to be used on their own.
