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