incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Code import
Date Wed, 18 May 2011 08:51:50 GMT
Hi Andy,
first of all: thank you.

Andy Seaborne wrote:
>> After infra have imported them, I'll do "svn copy"s to pull out the main
>> projects under /Jena2. This leaves us the choice of putting Jena3 under
>> "/Jena3" or as projects in "/" without needing to do a reorg.
>> /Jena2/Jena
>> /Jena2/ARQ
>> /Jena2/LARQ
>> etc etc.

Putting all the modules in the /Jena2 directory seems a good choice.
It does not pollute /.

We can continue as usual to manage the different modules as "independent"

By "independent" I mean that each module has a separate life cycles (i.e.
one module can be released without releasing all the other modules and
each module can have different version numbers)). Even if there are
dependencies between modules. ARQ does not work without Jena2. TDB does
not work without ARQ (and Jena2). Fuseki does not work without TDB. Etc.

Other projects within Apache or outside, chose to have the same version
for all the modules and release everything in sync.

At one point, I'd like to see a discussion on what are the pros/cons of
the two approaches and see if we want to change anything for Jena3.

>> The active CVS projects are "jena2", "iri", "Eyeball" 
>> "EyeballAcceptance".
>> /Jena2/Jena
>> /Jena2/IRI
>> /Jena2/Eyeball
>> /Jena2/EyeballAcceptance

Is there a reason why EyeballAcceptance is a separate project from Eyeball?

>> Presumably, the initial top-level trunk/tags/branches can go and we
>> continue to use a multiproject style svn.

Yes. We can always add them later if we need them.

Multi module projects which release all modules in sync typically use this

  - branches
  - tags
  - trunk

And below /trunk they have all the modules:

  - trunk/module-a
  - trunk/module-b
  - ...

All the modules (typically) end up with the same version number.

I am not saying we should do this (now or later), but I'd like to discuss
pros/cons of the two approaches and hear what other thinks about this.
I'll start a separate tread when we are settle down with the new SVN repo
and, maybe, we have done our first release (or SNAPSHOT) within Apache.


View raw message