incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Build experiments -- help wanted
Date Mon, 12 Sep 2011 13:10:37 GMT
Andy Seaborne wrote:
> 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.)


It would be, IMHO, a bad decision to make m2e (i.e. an Eclipse plugin a
requirement for working on Jena). I don't know what you can do with m2e
that you cannot do with the command line (i.e. plain Maven). I have no
idea which tasks m2e simplify, but as Benson said, people can use m2e if
they want to (but they don't need it to work with Jena).

Of course, if there are simple things we can do to make the life of m2e
users easier, why not?

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



>     Andy

View raw message