incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Help with parent POMs
Date Fri, 23 Dec 2011 16:12:34 GMT

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.

> The parent POM is overloaded.

>  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.

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



> 	Andy
> On 20/12/11 12:39, Benson Margulies wrote:
>> On Tue, Dec 20, 2011 at 8:08 AM, Paolo Castagna
>> <>  wrote:
>>> Hi Benson
>>> Benson Margulies wrote:
>>>> Putting repos in all the poms would be viewed as evil by many,
>>>> including me. Code moves, but released poms are forever.
>>> Which is more evil: having a duplicate<repositories>  section
>>> in each of the modules (with at least the Apache snapshots
>>> repository) or requiring everybody wanting to checkout and
>>> mvn package a Jena module to put the<repositories>  section
>>> in their settings.xml?
>> Paolo,
>> This is why people release their disconnected poms; it avoids this
>> dilemma. I'm not in favor of checking in poms that point to
>> disconnected parents via -SNAPSHOT. I'm in favor of picking from a
>> menu of two choices: release the parent, or make one big tree in which
>> everything is released together. If you pick one of those, you need no
>> settings.xml unless you want to hold an ASF release vote on multiple
>> releasable items at once, and then the only people who need it are
>> people testing the releases.
>> --benson
>>> I think making life of potential committers as easy as possible
>>> it's more important: svn co ... + mvn package.
>>> Another option is not to have the JenaTop parent pom.xml as
>>> SNAPSHOT dependency and use only JenaTop parents from Maven
>>> Central. This has the consequence that when a change in the
>>> JenaTop parent pom.xml is needed, we need to push it out to
>>> Maven Central as quick as possible. Not a situation I would
>>> recommend, in particular at the beginning when changes to
>>> the JenaTop parent still happen.
>>>> I'm sure by now you've realized the technical situation: since the
>>>> repo is declared in a parent the parent, that declaration is not
>>>> available when locating the parent in the first place (unless it is in
>>>> setting.xml).
>>> Or in the module's pom.xml itself.
>>> Little duplication for us (to maintain, I am happy to do the
>>> maintenance for that, I do not expect to change in the next
>>> few years!), no action required by anyone else in the Jena
>>> team or any future curios developer wanting to compile a Jena
>>> module.
>>> My 2 cents,
>>> Paolo
>>>> On Mon, Dec 19, 2011 at 10:02 PM, Andy Seaborne<>  wrote:
>>>>> On 19/12/11 21:32, Paolo Castagna wrote:
>>>>>> Benson Margulies wrote:
>>>>>>>> (Still haven't completely grokked why SNAPSHOT versions can't
>>>>>>>> pull down
>>>>>>>> SNAPSHOT parent POMs but life is too short.)
>>>>>>> Whoops, missed this question. Have you run 'mvn deploy' to push
>>>>>>> snapshot? Even if you have, the snapshot repo isn't in anyone's
>>>>>>> list by default. They would have to add it to their settings.xml.
>>>>>> Does adding a<repositories>    section in each of the modules
>>>>>> Maven cannot retrieve the parent pom.xml file from Maven Central
>>>>>> (which is the only repository available before retrieving the
>>>>>> parent pom itself).
>>>>> Ah - good point.  They are in the Apache POM which is jena-top's parent.
>>>>> Adding them to settings.xml causes things to work.  My bad.
>>>>>> It's not ideal because of the repetition, but if it works would be
>>>>>> not that bad (Apache Maven repositories are not going to change).
>>>>> Could do - there's<repositories>  in TDB and Fuseki currently 

>>>>> which current
>>>>> use the staged artifacts for testing.
>>>>>> My 2 cents,
>>>>>> Paolo
>>>>>        Thanks,
>>>>>        Andy

This message was sent using IMP, the Internet Messaging Program.

View raw message