In trying to reply to this, I keep coming back to teh release structure
and whether we want to JRE. (JRE = Just Release Everything)
This affects the repo structure (not so much the modules). It would be
nice for people to check out just a part of the project. It's possible
in git but it's convoluted [1][2].
If there are multiple git repos, I don't see how JRE would work except
as doing each repo in turn producing multiple source artifacts. There
isn't a single source artifact produced this way. (We could write our
build process that glues things togther).
I think we want to have JRE without excess plumbing and maintenance of a
build process. The partial fetch of Jena is an nice-to-have feature but
not at the cost of making other things harder.
So it seems to be that we have one (git) repo.
Within the one repo, we split up the modules into sub-projects. We
document/link to ways to pull part of the repo.
The only module that might benefit from being separate is jena-iri which
is very stable.
Does that make sense?
Andy
[1]
http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/
[2] http://briancoyner.github.io/blog/2013/06/05/git-sparse-checkout/
On 23/07/14 13:48, Andy Seaborne wrote:
Rob,
Excellent
I hadn't realised that TLP could have several git repos and for some
reason I was thinking it discouraged. (No idea where that belief came
from as it's clearly wrong.)
It solves the big problem I was noodling on - how to be able to work on
some of Jena without having to have everything cloned. It would (might)
be tolerable for us committers but opaque for people coming to jena
initially.
Andy
On 23/07/14 11:02, Rob Vesse wrote:
Hey All
Following up on the recent discussion points Andy raised around module
structuring as the project expands its scope and modules do we want to
think
about reorganising our repository and how we do releases?
For discussion lets consider splitting the current modules up into
several
sub-projects like so:
* commons - jena-iri and Claude's proposed jena-commons module
* core - jena-core, jena-arq, jena-tdb, jena-security
* search - jena-text, jena-spatial
* fuseki - jena-fuseki
* jdbc - All JDBC modules
* sdb - jena-sdb
* client - Stephen's experimental jena-client module
* hadoop - The jena-hadoop-rdf modules
(This is just an illustration, what goes in which sub-project can be
decided
later, this is intended to stimulate discussion rather than to be a
concrete
proposal).
So rather than having a flat trunk structure with each module in the
root we
would have a structure where each sub-project has a directory in trunk
with
its modules located under it. In this structure jena-parent then
lives in
the top level directory.
With such a structure we could then consider having different release
cadences for different sub-projects. So when we do a new core release we
would not necessarily have to release everything else at the same time
(though in most cases I suspect we would want to), however if a
sub-project
wants to make an interim release in the meantime there would be
nothing to
stop this happening e.g. making a critical bug fix, tracking a
sub-project
specific dependency release
Obviously doing this kind of restructuring would be really painful
with SVN
so might I suggest that any such change should happen in conjunction
with a
move to Git?
The other alternative to such a trunk structure is to have each
sub-project
live in its own Git repository which does appear to be something that
Infra
supports - the list of repos at https://git-wip-us.apache.org/repos/asf
shows multiple repos for several projects (Accumulo, ActiveMQ, Ant to
name
just three near the top of the list) - so we could certainly go down that
route if we wished? In that scenario then jena-parent would need to
live in
its own repository as well (probably the main jena repo would contain
just
jena-parent and pointers to the other repos). However this approach
would
complicate releases somewhat since you likely need to have multiple
release
votes and release artifacts since cutting a release might mean releasing
from multiple releases and each would need reproducible sources.
Thoughts?
Rob
