incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Fuseki build broken.
Date Tue, 10 May 2011 11:07:32 GMT
Hi Andy,
I reverted the changes. More details below.

Andy Seaborne wrote:
> On 10/05/11 11:15, Paolo Castagna wrote:
>> Hi Andy
>> Andy Seaborne wrote:
>>> Fuseki does not currently compile and some other things have changed
>>> without warning in such a way a build would affect a user:
>>> I would prefer that systems are always in a state whereby they can be
>>> built and released unless they is good reason and notification.
>> Yes, I agree.
>>> 1/ Depends on a non-existent TDB 0.8.11-SNAPSHOT
>> Sorry, I didn't spot this immediately (since I had TDB 0.8.11-SNAPSHOT
>> in my
>> local Maven repository).
>> Will publishing a TDB 0.8.11-SNAPSHOT fix the problem?
> But there are a mix of outstanding patches for ARQ and TDB.  What state 
> is Fuseki in?

If Fuseki depends on a SNAPSHOT (either ARQ or TDB) is in the same state

To release it, it must not depend on SNAPSHOTs so, either a dependency
on a SNAPSHOT is decreased to the latest stable release or a release of
the dependent module is necessary first.

When is the next Fuseki release planned?

>> However, at release time Fuseki will need to depend only on non
>> SNAPSHOT artifacts though.
>>> 2/ Introduces a dependency on talis-oss-snapshots Maven repository.
>> I'll remove this one.
>> Is it possible to have a SNAPSHOT for LARQ on the Jena's repo-dev?
> Yes - I have to do it because the file permissions are set up right and 
> I've never got round to fixing it.

It would be useful to have a LARQ SNAPSHOT on jena-dev, this way we can
try it or depend on it (from SNAPSHOT artifacts) without introducing
dependencies on other repositories.

I still need to check if it is possible (and how) for incubating projects
to use:

All committers should be able to publish SNAPSHOTs or a CI systems
should/could do this for us (every commit or daily).

> But this should not matter

It removes the dependency on talis-oss-snapshots Maven repository.

>>> 3/ Updating the dependencies does not get a working development system.
>> Could you expand on this?
> I updated Fuseki - it does not compile even after updating the 
> dependencies.

What was your problem?

Was it from Maven or from Eclipse?

It was compiling for me, both from the command line and Eclipse.

I was able to package a new Fuseki artifacts, run it and test LARQ was
functioning correctly. Indeed, this is what I did before committing
any change.

But, as I said, I had TDB 0.8.11-SNAPSHOT (and an updated ARQ-2.8.9-SNAPSHOT)
in my local Maven repo and therefore I did not see the problem.

>>> It also uses LARQ and seems to force Lucene 3 - isn't that a one-way
>>> migration isn't it?
>> LARQ in ARQ depends on Lucene v2.3.1
>> LARQ as separate module depends on Lucene v3.1.0.
> Yes - but what is the migration plan for LARQ?
> Is the next release of ARQ going to have just separate LARQ or a mixture 
> of internal and external modules? (seems kind of complicated).  When 
> does this happen?

To minimize problems and changes, I propose to release ARQ as it is
with the old legacy LARQ depending on Lucene 2.3.1 included.

However, I propose to commit the changes discussed in JENA-63 so that
it is possible and easy to enable and use LARQ (old or new from Fuseki
or other systems using TDB).

We could add the new LARQ (as separate module) to Fuseki.

In order to do this, Fuseki needs to depend on LARQ as well as on a
version of ARQ which includes the necessary changes to the DatasetAssembler.

This will make easy for users to enable and use LARQ with Fuseki.
They'll just need to add a line to their assembler config file.

Does this seem reasonable to you?

Having LARQ is Fuseki is really valuable IMHO.
Using the new LARQ keeps Lucene indexes up-to-date with TDB and it avoids
duplicates. This, IMHO, is another really valuable thing for LARQ users.


>> Some methods have been deprecated and then removed from Lucene v3.x,
>> therefore it is not possible to have a system using Lucene v3.x which
>> allows for a drop-in replacement if someone needs to an older version
>> of Lucene.
>> I can revert the changes, but having LARQ available in Fuseki is really
>> valuable for me (and I suspect many other Fuseki users).
> See above on migration plan.  Basically, what is going on? Suppose a 
> serious bug comes up in ARQ? TDB? Fuseki? can it be fixed and released now?

If a serious bug comes up in ARQ, it can be fixed a a new bug fix release
can be published for ARQ. ARQ currently compiles and all the tests pass.

If a serious bug comes up in TDB, same as above. Fix => bug fix release.
TDB currently compiles and all tests pass.

For Fuseki, since it depends on ARQ and TDB, there are two different

  1. Fuseki depends on ARQ or TDB SNAPSHOTs
  2. Fuseki depends on ARQ or TDB latest releases

In case of 1. if Fuseki needs the changes in ARQ or TDB SNAPSHOTs, a release
of Fuseki must be preceded by a release of ARQ or TDB.

>> Paolo
>     Andy

View raw message