incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Help with parent POMs
Date Fri, 23 Dec 2011 16:31:18 GMT
On 23/12/11 16:12, wrote:
> Quoting Andy Seaborne <>:
>> For the moment, I've set the parent POM to be "0-incubating" on the
>> modules released and TDB , SDB and Fuseki. So someone can check out a
>> module and "mvn dependency:resolve" have have a working local copy,
>> including Eclipse set up.
> Just did that for IRI (fresh checkout). All fine.
>> That creates us the space to decide which of the two options we use
>> longer-term.
>> I (currently) favour a disconnected parent POM.
> +1
>> The parent POM is overloaded.
> Indeed.
>> It's build config, project details, base dependencies, and pointer to
>> the Apache parent POM.
> Did you consider making use of dependency management (and plugin
> management) [1] for enforcing versions of dependencies in jena-top? At
> the moment, essentially the same thing is done, but using properties
> that specify the version instead.

Yes - that is how it's done currently, or nearly was but expediency 
steamrollered it.  The parent has e.g.


Using ${ver.*} puts the versions in one, short, place you can see all at 
once so it's just a variation.  The pattern didn't get fully rolled out 
and I copied down the versions into the POMs because of snapshot parent 
bootstrapping esp. in Jenkins.  (Sledge)hammer, nail, hit.

It does not work very well in the disconnected case.  It is (to me) 
highly desirable that it's clear in a release which versions are used. 
I would like to see the source-release at least have that information, 
and not pointing to an external place (the disconnected parent is not 
going to be in source-release of a single-trunk, multi-module release).

Hence ...

>> We could split out the common dependencies (Xerces, icu4j, junit,
>> slf4j,log4j) into some module as a root dependency: e.g.
>> jena-dependencies.
> -1
> As Einstein has put it succinctly: keep it simple, but not simpler.

... one place to name the dependencies for that version of Jena and get 
it into the source-release artifact.  At the moment, it's fixed in the 
parent which, if disconnected, has a different cycle.

That makes it a bit harder to upgrade external dependency versions - 
e.g. while working to remove ICU4J or at least get beyond 3.4.4 (later 
versions cause presumable false test failures in the IRI library). 
Changing the parent is a bit more costly in terms of process.


> Thorsten
> [1]

View raw message