Hello, > The naming is hard because we then have such a commitment to it.
Just to let you know that some libraries (e.g. CXF [1]) use the suffix "bundle" that seems to be a "common" word. My two cents. [1] http://search.maven.org/#artifactdetails%7Corg.apache.cxf%7Ccxf-bundle%7C2.7.2%7Cbundle On Thu, Jan 24, 2013 at 8:31 PM, Andy Seaborne <[email protected]> wrote: > 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. >
