You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Rob Vesse <rv...@yarcdata.com> on 2013/01/24 12:36:36 UTC
New Maven Modules?
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
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
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.
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.
Re: New Maven Modules?
Posted by Andy Seaborne <an...@apache.org>.
I have tested apache-jena-libs in a simple app and it works for me
(after I set the maven-compiler-plugin version to 6 or more)
I've updated the documentation in staging.
Andy
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
>
> 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
>
> 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.
>
> 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.
>
>
>
Re: New Maven Modules?
Posted by Dave Reynolds <da...@gmail.com>.
On 24/01/13 19:49, Laurent Pellegrino wrote:
> 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.
Actually I think "bundle" is mostly used specifically for OSGi bundles,
which is the case for CXF.
Dave
>
> 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 <an...@apache.org> 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.
>>
>
Re: New Maven Modules?
Posted by Laurent Pellegrino <la...@gmail.com>.
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 <an...@apache.org> 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.
>
Re: New Maven Modules?
Posted by Andy Seaborne <an...@apache.org>.
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.