incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject Re: Graduation & code re-org
Date Wed, 25 Apr 2012 07:51:41 GMT
Stephen Allen wrote:
> On Tue, Apr 24, 2012 at 9:54 AM, Andy Seaborne <> wrote:
>> On 24/04/12 17:07, Robert Vesse wrote:
>>> That looks good, it would certainly be nice to have a single parent POM in
>>> the top level directory so I can just hit mvn package and build
>>> everything.  Currently I have all the modules I care about checked out in
>>> adjacent directories and have a bash script in the top level directory
>>> which does a cd and mvn package on each subdirectory
>>> Having something pure maven would be much nicer.
>> Yes!
> +1
>>> On the subject of further reorg I would propose that like previous
>>> discussions from a couple of months ago we first get a post graduation
>>> release of at least the core components out the door branding with
>>> incremental version numbers.
>> Yes - this would be an incremental version numbering (aside from the
>> s/-incubator//g!)
>>> Then we immediately work towards refactoring
>>> everything to be in the org.apache.jena package and do a major version
>>> release with the repackage change only (assuming we decide that
>>> standardizing package names is the way we want to go long term?)
>> This is balancing act of much trickiness.
>> And we ought to use JENA-192 (Jena java package renaming) -- I'm as bad as
>> everyone else on splitting between email and JIRAs.
>> We know that version roll over is quite slow and that discontinuous change
>> can lead to a long tail.
>> I'm currently in favour of cloning the API, that is having com.hp.hpl.jena.*
>> and also org.apache.jena.*, the leaving c.h.h.j alone (complete
>> compatibility) and making improvements to o.a.j.
> Would it be possible to have the c.h.h.j.* classes living in a
> separate optional compatibility jar?  It would be nice to be able to
> remove it if you've switched fully to the new API.  Would this be
> harder than having them in the same jar?

If possible, having the old c.h.h.j classes in a separate (and optional)
jar is a very good idea.


> One thought is new user confusion when their Eclipse autocomplete
> brings up two copies of every class.
>> I haven't tried this out but the graph layer should provide the necessary
>> abstraction.  if it doesn't we need to change it.
>> There are various simplifications to the core graph layer to make it faster,
>> easier to extend (up and down) and most importantly, lower support costs.
>>  This is learning from what worked and what didn't, and reflect how RDF has
>> moved on.
> +1 on simplifying
>> e.g. reification  This has not taken over the semweb world.  We can provide
>> standard mode in code and not make any requirements on storage, and in fact
>> TDB already has to do this.

View raw message