+1 to all, are you reading my thoughts? ;+) On 26 Jan 2015 19:28, "Rob Vesse" <[email protected]> wrote:
> 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 > > > > > > >
