Quoting Andy Seaborne <a...@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.li...@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<a...@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.


Reply via email to