incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: Fuseki+ARQ release cycle
Date Tue, 07 Feb 2012 16:56:58 GMT
On 07/02/12 00:54, Robert Vesse wrote:
> I wanted to raise an issue with the upcoming Fuseki release which is
> that the release will rely on ARQ 2.9.0 which has a number of known
> issues particularly around the RDF/JSON and TSV formats most of which
> have since been fixed in trunk (aka 2.9.1-SNAPSHOT).
> The current version of our software here at Cray already uses a
> patched version of Fuseki 0.2.0 because there were some patches we
> really needed but management would not approve use of a snapshot.
> With some of these issues in ARQ 2.9.0 I'm already thinking that what
> we'll end up doing is using a patched version of Fuseki 0.2.1 for our
> next version because again there are bug fixes we'd really like to
> pick up.
> Therefore what I'd like to propose is that one of the following
> happen:
> 1 - Fuseki 0.2.1 releases with ARQ 2.9.0 as its dependency but that
> fairly shortly afterwards there is a 0.2.2 release to coincide with a
> ARQ 2.9.1 release

This would be good but as you point out, it also requires a TDB release.

If Paolo is OK with it now, I want to do a Fuseki release just as soon 
as TDB is finished with.

If "we" (you? :-) also check that the Fuseki jar, not the 
all-in-one-server-jar, works with ARQ 2.9.1-SNAPSHOT and TDB 
0.9.1-SNAPSHOT then at worst you can build your own server jar or run 
from the jena-fuseki jar + upgraded ARQ and TDB.

The Fuskei build does create the regular maven artifact 
jena-fuseki-VER.jar as well as jena-fuseki-VER-server.jar.

Rob - Does that make sense to you?

(Aside, all readers:

Checking and voting, even if not binding, is not restricted to Jena PPMC 
and committers.  We're going to listen to any feedback.

If your organisation depends on Jena, then you should be thinking of 
checking releases or (ideally) the snapshot builds.

> 2 - Fuseki 0.2.1 releases at the same time as ARQ 2.9.1 and uses
> 2.9.1 as the dependency i.e. there is never a Fuseki release that
> uses ARQ 2.9.0

I don't like this because of the delay it'll introduce in getting a 
Fuseki out.

If it is checked that it works with ARQ 0.9.1-SNAPSHOT then anyone can 
build their own Fuseki as soon as ARQ 2.9.1 is out if necessary.

> I suspect option 1 would probably be preferable to most people
> because I assume the soon to be released TDB 0.9.0 depends on ARQ
> 2.9.0 so if the ARQ version were to be bumped then there would also
> need to be a TDB re-release in short order but I'd just like to put
> this out there for discussion.

Beyond that, there are a clutch of JIRA for discussions

JENA-189 : Jena3
JENA-190 : Jena delivery
JENA-191 : Jena module structure and build
JENA-192 : Jena java package renaming.
JENA-193 : Changes needed, or desirable, for RDF 1.1

JENA-190 and JENA-191 are most relevant.

If we do the simple version for JENA-191 (a single trunk, multi module 
build) we will be able to have a single build of everything soon after that.

Doing the svn reorg is a short job although it is disruptive to anyone 
using SVN (and the Jenkins setup).

I think we just have to bite the bullet and do it as soon as possible.

We can then add on delivery modules (JENA-190), restructure in a more 
incremental fashion.  The first step is a "big bang" though.

The key is really getting the build shaken down.  There are enough 
assumptions around that it needs to be debugged.  e.g. the log4j 
properties issue and commands.   The old builds were fine - we have used 
them many times and, ugly or not, they worked and we all knew what to 


View raw message