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