incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <>
Subject Re: TDB: release process
Date Thu, 02 Feb 2012 10:06:44 GMT
On 02/02/12 08:34, Paolo Castagna wrote:
> Hi Andy
> Andy Seaborne wrote:
>>> Do you have a plan for LARQ?
>> No plan whatsoever.  I am at the limit of the number of things I can
>> manage.  I was hoping you would deal with LARQ.
> Ack. I know you are busy.

It is not about me being busy.  I should not be the only do doing 

Getting the first release of Fuseki out, Apache licensed, is important 
as it establishes the codebase as clean.

Referring to snapshots and the version confusion has not been helping on 

>>> In relation to Fuseki, JENA-63 is still open/pending:
>>> But, if Fuseki is released first... LARQ cannot be included in it
>>> and JENA-63 can only be closed with the next Fuseki release.
>> Do you want the release of Fuseki held up?

I have staged TDB and pulled the Fuseki release but that's because there 
is an issue with the zip build of Fuseki.

Talis want TDB released surely?

> Well, my colleagues who have used Fuseki to manage/explore their
> data on their machines, found free-text "searching" very useful
> (and I needed to tell them to always patch Fuseki to add LARQ to it).
> Patch is currently tiny and just a dependency on the Fuseki's pom.xml:

Arguments based on "colleagues" don't work for me.

If Talis/Kasabi is managing to usefully use it for their business then 
great but it's all a black box to me, except for support time when you 
direct people to jena-users@.

It is a few lines of maven for LARQ to depend on Fuseki and build it's 
own extended jar.

This unlinks the release dependency.

It allows LARQ to release to a different cycle to Fuseki. We can't 
release Fuseki just for bug and enhancements in LARQ.

I hope that updateable indexes happen - but making Fuseki have to 
release for such a new feature seems a bad way to do it.

See also JENA-190.

.. patch to Fuseki POM only ..

> We also had people asking for LARQ (and Fuseki) on the mailing list
> since we moved to Apache.

We have more people asking about protocol and Fuseki.  Getting a Apache 
Fuseki out is important to me.

> The best scenario for me would be:
>   1. TDB is released first
>   2. LARQ and Fuseki are released soon after (with JENA-63 fixed/closed)
>> LARQ does not work SPARQL Update or with SPARQL Graph Store protocol.
> Yes, we discussed about this already.
> This is a known (and important) limitation. There is an open issue on
> this:
> It isn't a blocker to me my mind.

JENA-164 blocks JENA-63 (your entry in JIRA on 11/Nov/11).

> I'll document the known limitation.
> Re: JENA-164, you know the "update" route into Fuseki much better than
> I do, if you could just add a small comment (i.e. one or two paragraphs)

The JIRA points to an email thread from Oct 2011 that deals with the 
bulkloader problem.

And I've suggested LARQ could create a DatasetGraph and catch every 

A LARQ assember could simply name the dataset description it wraps. 
Assemble the LARQ assember assembles the inner dataset.  Fuseki service 
points to LARQ.

Seems quite practical to try to me.

But I'm not going to do it.

> on how this could be done... without big changes on the event/notification
> system, I'll do it. I have time tomorrow and probably next week.
> The problem I have with JENA-164 is that I do not see how I can "intercept"
> changes without changing Fuseki code.
>> We see on jena-users@ that people are using Fuseki via the update
>> protocols.
> Yep.
> All the people I saw using Fuseki (and LARQ) at work they were loading
> stuff with tdbloader(2) and then "exploring" the data (i.e. a read-only
> scenario).
> RDF publishing systems are often used in a mostly read
> scenarios, with little/few updates. In this case, rebuilding the Lucene
> index nightly would be a reasonable workaround, until JENA-164 is fixed.
>> Could LARQ be released separately as a bolt-on to Fuseki, with
>> instructions on how to build and maintain the index?  I presume you want
>> to say its for read-only publishing at the moment.
> Yeah.
> I am not sure what you exactly mean "as a bolt-on to Fuseki".
> My colleagues love the fact that Fuseki is just a single jar file (with
> all the dependencies). LARQ is an extension which can simply added to
> the classpath (together with Lucene) (i.e. two jars).
> People wanting to use LARQ with Fuseki will need to repackage Fuseki
> if they want the single jar file with LARQ in it.
> A similar scenario will arise for GeoSPARQL (i.e. another cool SPARQL
> extension I/we would love to see/have and use in Fuseki).
> I can see how this can become a problem.

Well, there is no activity on GeoSPARQL so the whole issue there is moot 
for this release cycle.


> On the other hand, Fuseki is so easy to checkout/build/package that
> even if LARQ isn't included in it... people can package it themselves
> or third parties could distribute a pre-packaged version with all the
> cool extensions in it (not my preferred options for various reasons).
>> I'll hold things up for a day while we discuss this.
> Thanks.
> Paolo
>>      Andy
>>> Paolo
>>>>       Andy

View raw message