On Tue, Apr 24, 2012 at 9:54 AM, Andy Seaborne <a...@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? 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.
