Stian,
Something has to be done in order to do things you have been arguing
for, such as reducing class loading. This is about development
internals. Other have wanted/suggested more module structure.
If change is happening, we can at least start with a separation because
it enforces (=checks) that RDF-isms aren't creeping in. You make valid
reasonable points though the gating criterion of positive advantage
isn't one I agree completely with.
Whatever happens, we can move it into core later. At the moment,
getting things clean is the majority of effort, not the location, and
the split spots issues as I have been finding.
And, yes, I'd find it useful elsewhere - I have a prototype TDB-NG that
has clearly defined file abstraction, copy-on-write indexes and a
generalised transaction manger. Making sure those don't get depend on
RDF-isms is a useful software engineering discipline.
>> Would not jena-iri fit in jena-base?
jena-iri already exists and has a clearly defined functionality.
Andy
On 28/04/15 17:36, Claude Warren wrote:
Stian,
Good question. I was thinking that it would be usefull for some of the
testing code to depend on it, but as I think of it your point that
everthing is dependent upon core anyway raised doubts in my mind.
I have not looked into base yet to see what is there.
Nothing yet in the repo.
I've moved stuff in locally to check and sort out dependencies (see
recent commits as to things that I have discovered). Not all of
oaj.atlas will move in jena-base easily. I've improved obvious things
but a couple of packages look to be more tightly related to ARQ, even if
it's only a system constant that ties them in; that would be a
functional change that needs agreeing first.
Claude
On Tue, Apr 28, 2015 at 3:51 PM, Stian Soiland-Reyes <[email protected]>
wrote:
So what is then the difference from jena-base and jena-core? The base
is utillity non-RDF stuff, and jena-core basic RDF?
I am not too sure about creating a new module which everyone will
ultimately depend on through jena-core anyway.. what benefit is there
from a separate module rather than just a new package under jena-core,
given that everything will be released together anyway and (as far as
I can tell) only jena-iri does not depend on jena-core?
Could jena-base be useful for outside projects independent of
jena-core, or is it more of a kind of "only for internal Jena use"?
(E.g. an old libjena-iri-java appears separately in Ubuntu/Debian)
On 25 April 2015 at 22:32, Andy Seaborne <[email protected]> wrote:
As part of rearranging the code, I'd like to propose we have module
"jena-base"
It would be non-RDF related code, seeded with what is currently
org.apache.jena.atlas which is in jena-arq and is then used by TDB and
SDB
and others. RIOT uses it so it is a prequiste for moving RIOT.
Depends on:
jena-shaded-guava
Is depended on by:
jena-core
which can then use the cache code, based on guava via oaj.atlas.
Now we have java8, it is quite possible that stuff in oaj.atlas can be
slimmed down and also oaj.atlas renamed.
"jena-commons" is also a possible name but in trying this out, I found
some
code using configuration settings, based on Context. A JVM wide Context
would be useful. So its role is not just library code but also some
small
amount of state.
And JenaException
While in theory, it should be simple to migrate code, there are some
dependencies out of atlas that have sneaked in.
I would start by moving a package at a time, clean ones first. This can
happen incrementally.
Andy
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
