incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Build experiments -- help wanted
Date Mon, 12 Sep 2011 12:15:54 GMT
Thanks to everyone for the comments - it does come down to "it depends" 
and we have choices, rather than a few fixed paths.  The tool chain oes 
seem to hold up a bit better than it used to as well.

On 07/09/11 20:48, Benson Margulies wrote:
> m2e is very problematic. It is very ambitious and notably incomplete.
> Some people are sticking to the maven-eclipse-plugin, some people are
> switching to intellij, and some people are choosing to live with it as
> it is.

I think you're right in saying m2e is being quite ambitious and I'm not 
sure that we need to all share it's complexity.  Also, it's a bit 
all-embracing and makes a particular Eclipse setup first amongst equals.

I'm tending towards an incremental approach whereby we can moved towards 
a complicated scheme as and when it all works out rather than get struck 
basing the tools together.

At least for now, I would be nervous to jump to making m2e, de facto, a 
requirement for working on Jena; if nothing else, being able to fairly 
support other IDEs.  (I know m2e does not become an absolute requirement.)

Once the POMs are set up (non-trivial), then I don't expect structural 
changes to be common, so with dependencies in the (published) top POM, 
most of the churn editing and releasing that POM.  We'll need to version 
it separately.

Working on just one module without everything seems to be me to an 
important feature.

On hierarchical vs flat, I'm inclined to go flat for now because it's 
how the codes currently arranged.  At a discontinuity like the start of 
Jena3, we can revisit - maybe then a top project with all the subsystems 
and delivery modules side-by-side under it.  Either way works.

One key question is whether components have their own version numbers. 
We currently have separate ones.

So for Jena2 Apache releases, we keep the subsystems as relative 
independent entities, with their own version numbers.

There are various fun things to get working - currently, most of our 
subsystems burn their version number and build date into their jars, 
requiring a little dance with antrun.

Summary: we could burn a lot of time here - let's sneak up on the 
problem and start with a parent POM, leaving things structured as-is. 
Spend the time on getting Apache-acceptable releases.


View raw message