incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: Build experiments -- help wanted
Date Mon, 12 Sep 2011 12:20:15 GMT
On Mon, Sep 12, 2011 at 8:15 AM, 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.

If your maven poms are straightforward, the maven-eclipse-plugin works
reasonably well. If you like checkstyle and pmd to be in sync, you can
borrow the tricks from Apache CXF. Anyone who *wants* to use m2e is
welcome to do so. You can put m2e exclusion declarations into the poms
without disturbing anything else.

It's common for Apache projects to publish some exported Eclipse
settings for indentation and the like, and do likewise for other IDEs.
In other words, a good goal is to be IDE-agnostic.

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

View raw message