On 26/01/15 19:27, Rob Vesse 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
Agreed.
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
You persuade me ...
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.
Yes - it works nicely once it's set up.
I think whether to have jena-riot or packages in core is by and large a
internal project issue. Code isn't that large, few dependencies from
RIOT. It does enforce a clean separation.
I can think of one catch - it would be nice (and only "nice") to add
enum-like constants to the model.read operations to avoid the
string-confusion.
Currently, in oaj.riot.Lang.
Some subclassed ones in core would work ... but feels like getting
technical debt even before a Jena3 is released.
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.
Yes!
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
