Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of castagna.lists@googlemail.com
 designates 74.125.82.175 as permitted sender)
Message-ID: <4F97AD0D.7010202@googlemail.com>
Date: Wed, 25 Apr 2012 08:51:41 +0100
From: Paolo Castagna <castagna.lists@googlemail.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: jena-dev@incubator.apache.org
Subject: Re: Graduation & code re-org
References: <CBBC1CCA.DBF1%rvesse@yarcdata.com> <4F96DACA.9040801@apache.org>
 <CAPTxtVOVNghN501a+CjYVt-z1SRZQXu9B8ih4CADr8R01GVivQ@mail.gmail.com>
In-Reply-To: 
 <CAPTxtVOVNghN501a+CjYVt-z1SRZQXu9B8ih4CADr8R01GVivQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Stephen Allen wrote:
> On Tue, Apr 24, 2012 at 9:54 AM, Andy Seaborne <andy@apache.org> 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.

Paolo

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