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"
modules/projects.
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
layout:
- 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.
Paolo
