This message is a collection of thoughts on reworking the build process.
It's not a complete proposal.
== Current Status
Subsystems (to avoid the "module" word)
Jena, IRI, ARQ, LARQ, TDB, SDB, Fuseki
The current build system is a one maven project per subsystem. Each
subsystem produces a single download zip file and also deploys artifacts.
The builds are linked by version dependencies in the POM files. There
is a hack to get ARQ into the Jena download to break the circular
dependency.
== Goals
These are my take on desirable features, not necessarily absolute
requirements, so if it isn't practical to achieve it in the overall
system, then a goal can be modified or removed.
+ Balance cost of change and benefit (we don't have to start with a
clean sheet - we can leave some thigns as they are, because they are).
+ A single download zip file for using Jena as a library
+ A single jar file for using Jena as a library
The main download should be complete - everything you need to write a
Jena application using Jena as a library. I'd like to change to having
a single zip that is current Jena + ARQ + LARQ + TDB (maybe?). That
puts datasets adn quads into Jena core. (Some API changes could also
happen to make this feel more integrated.)
It also seems easier to deliver a single jar for this.
And a single obviously-named Maven artifact - at the moment, a single
dependency to pull is e.g. TDB because that pulls in the rest, which
isn't exactly obvious.
Other goals or considerations?
== Possible build layout.
Divide the overall project into a number of maven modules for building
parts of the system and a number of projects for making deliverables.
Just the code modules would mean you can work from a set of many jars
and mix and match for development etc. Application writers can get a
single consolidated jar.
Jena-top-POM -- common declarations, a lot of properties getting set.
Code modules:
JenaSys
-- This is the current Jena2.
How much do we want to split it up?
Is it worth the effort?
core = graph + datatypes
RDF API (inc enhanced?)
owlapi
rules
Assembler? Here? Module of it's own?
IRI
Atlas -- Non RDF specific stuff.
RIOT
-- ideally Jena-code+RIOT is a useful set
-- Move ARP and XML output here or separate module again.
ARQ
-- minus atlas, and RIOT
TDB -- transactional
SDB
RDB? Legacy or remove once and for all.
Documentation = website only.
Deliver modules:
Jena -- the deliverable: one jena-the-jar and zip file.
JenaCmd -- Command line things: Jena+ARQ+TDB commands
Fuseki is a separate module and deliverable. It uses combined Jena as a
dependency but does not need to be part of the library build.
Eyeball is a separate module and deliverable. It uses combined Jena as
a dependency but does not need to be part of the library build.
=== Questions and notes.
1/ We currently make some attempt to deliver the test suite in the zip
so people can locally run it to check an installation. From memory, the
only thing this seems to catch is problems running the test suite, not
problems with installation. Maybe it's not worth the effort.
2/ The Apache top level POM has a list of versioned plugins in it which
we'd inherit. Hopefully it helps with an Apach release but it does seem
quite a lot. The default compilation is Java 1.4 -- we need to check
details.
3/ For RDB, I propose creating a maven module and putting the code here
with a dependency of whatever version of Jena it is at the time then
leaving it frozen. Alternatively, zip up the code and dump somewhere in
case anyone wants to port it.
4/ Shall we leave the documentation out of the build and just have it on
the website?
5/ Jump to maven 3?
