Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <20111223171234.20734kfvrlumtgtu@webmail.unibas.ch>
Date: Fri, 23 Dec 2011 17:12:34 +0100
From: Thorsten.Moeller@unibas.ch
To: jena-dev@incubator.apache.org
Subject: Re: Help with parent POMs
References: <4EEF74DF.5050707@apache.org>
 <CALhtWkct1z=VjqM29RpFLV99ZrkJAt2M7wY8bZvaDVMq4aN2Mw@mail.gmail.com>
 <4EEF7A3E.1030605@apache.org>
 <CALhtWkfQmHYKfpW+W_2H=9cPXBrQuMdeFRW9MTwy3KgT0ddQsw@mail.gmail.com>
 <4EEF90B9.4040904@apache.org>
 <CALhtWkdF2ceuRjthfNGmhss6EataZhM9x1KoJtaDO4KxvPnHOQ@mail.gmail.com>
 <4EEFAD60.4020906@googlemail.com> <4EEFB480.3000108@apache.org>
 <CALhtWke3Qzo36cbS+7N2kXHqnAp-nt9QLYZU4z7js5deCG+UKA@mail.gmail.com>
 <4EF04284.5040306@googlemail.com>
 <CALhtWkemvhtU=TGhkVZ0P7nvAatEmjmd2_+-DFR+++ohy4X23A@mail.gmail.com>
 <4EF4A21F.8080804@apache.org>
In-Reply-To: <4EF4A21F.8080804@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=ISO-8859-1;
 DelSp="Yes";
 format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4)


Quoting Andy Seaborne <andy@apache.org>:

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


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


Thorsten

[1]  
http://stackoverflow.com/questions/2619598/differences-between-dependencymanagement-and-dependencies-of-maven


>
> 	Andy
>
> On 20/12/11 12:39, Benson Margulies wrote:
>> On Tue, Dec 20, 2011 at 8:08 AM, Paolo Castagna
>> <castagna.lists@googlemail.com>  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<andy@apache.org>  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 the
>>>>>>> snapshot? Even if you have, the snapshot repo isn't in anyone's repo
>>>>>>> list by default. They would have to add it to their settings.xml.
>>>>>>
>>>>>> Does adding a<repositories>    section in each of the modules help?
>>>>>> 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.