Andy I would prefer proposal two, Jena 3 will be disruptive regardless (if only because of the time people spend updating import statements). A few other more minor changes to import statements and POM definitions wouldn't be too big of a deal IMHO
I would be strongly against leaving old package names with redirects since it only encourages people to not bother migrating code properly and just to simply update the version in the POM and not be aware that there are other changes that happened (e.g. RDF 1.1). A one time disruptive migration forward to Jena 3 that makes me actually have to consider the impact of the migration on my existing code is strongly preferable to a staggered migration In that vein I would suggest that the IO components be moved into their own package (jena-riot I assume?) at the same time, again the principle is to make people take a single larger disruptive migration rather than requiring many smaller migrations. If Core needs to have some way of wiring in IO automatically then I suggest we do it via the Java 7+ ServiceLoader mechanism, I'm already using it a little in the Elephas IO modules and it works pretty nice and I would be willing to help get this set up for Jena 3 IO as necessary. I suppose the IO wiring comes back to the question of whether Model.read() and Model.write() are still relevant or if we force everyone over to using RDFDataMgr (which would be my preference) since the IO module has to rely on Core anyway for the relevant data model APIs and having Core somehow rely on IO is an ugly circular dependency (or gets us into the same problems we have now). Of course the alternative solution to that is to have the Resource API also broken out into its own module so that Core really is only the core low level data structures. With regards to packaging if people are using higher level POM artifacts like apache-jena-libs then the module changes should remain fairly transparent to them. Rob On 24/01/2015 10:34, "Andy Seaborne" <[email protected]> wrote: >[[ >oaj = org.apache.jena >chhj = com.hp.hpl.jena >]] > >One major possible change target is the core/arq split. > >Much of this comes down to where quads/datasets go in the package tree. > They started as a SPARQL (1.0) feature but are now RDF 1.1 and parser >related. > >The general idea is move dataset/quad support to core, move parsers to >core (separate into their own package later??) and have jena-arq be >SPARQL only. > >The question is how much change to go through to achieve that > >Possibility 1 : Less change > >Move DatasetGraph* to oaj.dataset.* > >API visible: > >Migrate Dataset from chhj.query.Dataset to oaj.rdf.dataset (c.f. >oaj.rdf.model) > >Move DatasetGraph and Quad to oaj.dataset (c.f. oaj.graph) > >Try to leave indirection class in chhj.query.Dataset somehow. > > >Possibility 2 : More change, more disruption (but one time) > >Pull oaj.rdf.model up to oaj.rdf and put Dataset there. This is the >"RDF API". > >Use oaj.graph for DatasetGraph and Quad. > >Hmm - actually writing this down, I am tending towards possibility 2 if >that works as cleanly as it sounds. > > Andy >
