incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Jena build (some thoughts)
Date Thu, 08 Sep 2011 19:34:03 GMT
Dave Reynolds wrote:
> 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.

Hi Dave,
just to make sure I understand your position.

Do you mean "a single jar" in addition to separate jars (one for each of the
Jena modules, for example: tdb-x.y.z.jar, arq-x.y.z.jar and maybe new jars
such as riot-x.y.z.jar, atlas-x.y.z.jar and a small jena-core-x.y.z.jar
(exact list yet to be decided))?

Or, do you mean just "a single jar" instead of separate jars (one of each
of the Jena modules)?

We (@ Talis) quite like having different modules and it allows us to easily
patch one module and we would like to avoid including what we do not use
in our class path. (We had troubles with Xerces and Saxon, just to give an

Another scenario is MapReduce. When you write MapReduce jobs you often just
want to parse N-Triples or N-Quads files, so a small jena-core.jar and riot.jar
would do. You don't want to upload ~20MB jar just to parse N-Triples and if
you have an interactive algorithm with a sequence of MapReduce jobs (and you
use Amazon EMR jobs, as sometimes we do) it's a pain to upload the ~20MB each

A similar argument (i.e. better modularization) is what pushed projects such
as Any23 away from Jena in favour of Sesame, for example. I can relate to that
and I understand why.

Again, having a big and monolithic Jena jar (with a dependency on Xerces)
has caused problems to people wanting to run Jena on Android even if they did
not wanted to parse RDF/XML (not something I personally need, but why not to
put Jena in a position where this would be possible and easy?)

Another argument in favor of a few smaller modules is that it's easier for
others to join in, understand a smaller code base and contribute to it.
Other projects (for example Any23 or Clerezza) might benefit as well and/or
use a tiny apache-jena-core.jar or riot.jar and (why not) even contribute to

These are a few reasons why I would not be in favor of "just a single jar"

To me, "a single jar" is good and it's not something I am opposed to, but
in addition to a jar for each of the modules (and we should discuss what
these modules should be).

> 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)

We don't use OSGI, but if it's easy to do and it help others, why not?

> 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. 

I am not an expert of OSGi, however a chunky jena-one-jar including all
the third party dependencies is something I would say "unusual" and certainly
something we would not use. I am not so sure who would find that useful.
But, maybe I am wrong.

> 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 :)

Support cost on classpath issues seems to be not much (maybe it's better
documentation, maybe people are learning how to use Maven, who knows).

However, a single jar is really useful to run command line utilities or
applications such as Fuseki.

So, I do not oppose to this, but I would not like to lose the opportunity
for a better modularization of Jena.

I believe we can have "single jar" and separate modules (and from what you
wrote below) it seems we are on the same page on this.

However, I wanted to double check.


>> == 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

View raw message