Stephen Allen wrote: > 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?
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.
