On Tue, 2011-09-06 at 13:06 +0100, Andy Seaborne wrote:
[Great set of thoughts.]
> == Goals
[snip]
> + A single download zip file for using Jena as a library
>
> + A single jar file for using Jena as a library
+1 for goals overall and for the notion of a single jar.
I'd like (as in, I would put work into this) to also have osgi support.
Suggest:
o the jena-one-jar would also be marked as an OSGI bundle (easy to do
via maven bundle plugin)
o a third top level download, jena-complete, which is the jena-one-jar
plus dependent jars (i.e. xerces, slf4j/log4j etc) packaged as an single
jar/OSGI bundle.
The latter is not *necessary* for OSGi support but the way we/I
currently work with OSGi makes it easier to have reasonably chunky
self-contained bundles than do the fine grain dependency management at
the OSGi level.
This can also be used via "java -jar jena-complete.jar ..." to run any
of the command line utilities which would save some support list load on
classpath advice :)
> == Possible build layout.
OK with going for maven multi-module project structure.
Given comments on the "Build experiments" thread I wonder if we a want
sub-project structure as well. A possible structure might be:
Jena sub-project
modules
JenaSys
IRI
Atlas
RIOT
ARQ
TDB?
Jena (one jar and zip) - just for building integrated artefact
JenaComplete - just for building integrated artefact
Website sub-project
SDB sub-project
Fuseki sub-project
Eyeball sub-project
So sub projects can be independently checked out and the Jena
sub-project can then be hierarchical.
If we went the sub-project route then it might make sense to have TDB as
a separate sub-project as well since that is under more active
development. Depends partly on whether we feel TDB should be part of
jena-one-jar or separate (I noted your "maybe?" on that, have no settled
view myself).
> === 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.
Not worth the effort.
> 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.
Prefer former (create module then leave frozen) but OK with either.
> 4/ Shall we leave the documentation out of the build and just have it on
> the website?
Yes, except for some minimal "getting started" documentation in the zip
that references the website for details.
> 5/ Jump to maven 3?
If that risks any increase in maven/m2e unpredictability then no :) but
I've no knowledge of what the specific issues might be.
Dave
