incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: svn commit: r1174281 - in /incubator/jena/Jena2/SDB/trunk: lib-src/ lib/ src/com/hp/hpl/jena/sdb/layout1/ src/com/hp/hpl/jena/sdb/layout2/
Date Fri, 23 Sep 2011 14:44:07 GMT

Andy Seaborne wrote:
> On 23/09/11 13:21, Paolo Castagna wrote:
>> Andy Seaborne wrote:
>>> On 22/09/11 19:53, Paolo Castagna wrote:
>>>> wrote:
>>>>> Modified:
>>>>> incubator/jena/Jena2/SDB/trunk/lib-src/arq-2.8.9-SNAPSHOT-sources.jar
>>>>> incubator/jena/Jena2/SDB/trunk/lib-src/arq-2.8.9-SNAPSHOT-test-sources.jar
>>>>>       incubator/jena/Jena2/SDB/trunk/lib/arq-2.8.9-SNAPSHOT-tests.jar
>>>>>       incubator/jena/Jena2/SDB/trunk/lib/arq-2.8.9-SNAPSHOT.jar
>>>> I think we should drop these.
>>> And break SDB completely?
>> No. Why?
> The development system relies on those jars as does the distribution. It
> hasn't been changed to the new world order (ditto TDB).

I think we should remove those files and change the development system
as well as the distribution in such a way that those files are not used
(as you have done for ARQ, Fuseki, TxTDB and as it's the case for LARQ).

I just want to know if it's just a matter of time or there are other
reasons why those files should not go away.

I am happy to fix this for SDB if we agree on removing those files.

>> SDB latest release will be unaffected by the change.
> This keeps SDB development up-to-date with internal changes in ARQ.

LARQ or Fuseki development are up-to-date with internal changes in ARQ
without having the lib or lib-src directory, but simply depending on
ARQ-x.y.z-SNAPSHOT. This is what the majority (if not all) projects using
Maven do.

> I prefer that to having to go back much later and remember how to carry
> out all the changes.

I agree.

I am proposing to have SDB depending on ARQ latest SNAPSHOT and avoid
having to manually update jars in the lib or lib-src directories.
Manually == error prone (i.e. someone, soon or later, will forget to do
that, or will do it wrong). Also, if you do not do it or forget... and
the SNAPSHOT changes, you risk of not spotting problems.

>> SDB development version can choose to depend on ARQ latest stable release
>> or ARQ latest SNAPSHOT. In this case if someone does something which
>> would
>> break SDB, Jenkins will spot it (and it will get fixed immediately...
>> i.e.
>> continuous integration (without manual intervention to update jars in the
>> lib directory).
> ?? It did.

Yes, because we have two set of jars (a set is used by Maven and another set
is used by Eclipse). This has caused me problems (more than once) when I was
working on two different modules (one of which had this two set of jars).

You publish a new SNAPSHOT, nothing breaks in Eclipse in the other module.
But, it breaks Maven.

>> I still think we should remove jars from the various modules.
> There is still a manual step, it is just moved to development - after
> svn update, you would have to do a "mvn dependency:resolve
> dependency:sources".
> I have ensured there is script, mvn-update, that does the right thing
> for each module.

I still think it's better to have Eclipse and Maven use the same set of jars.
It avoids people making mistakes and ensure that what you see in Eclipse is
always what you get with Maven from the command line and vice versa.

At the moment the situation is:

 - ARQ    --> 1 set of jars, no lib directory, .classpath points to M2_REPO
 - LARQ   --> ditto
 - TxTDB  --> ditto
 - Fuseki --> ditto

While these modules are not there yet:

 - Jena2  --> 2 set of jars (one for Eclipse, one for Maven)
 - IRI
 - SDB
 - Eyeball
 - TDB

I am in favor of bringing the situation for Jena2, IRI, SDB and Eyeball as
it is right now for ARQ, LARQ, TxTDB and Fuseki.

And I am ready to help (or do it) if we all agree it's a good thing.


>> Paolo
>>>      Andy
>     Andy

View raw message