Makes sense.
jena-base comes before any RDF code.
One hazy area I found is some IRI handling for filenames to make
"file:///" work. At current approximation, the part of IRILib for file
IRIs should go in jena-base for seemless filename handling. But that's
"web" not "RDF". jena-base shouldn't need to depend on jena-iri; the
"file:" is string mangling, not deeper parsing.
Andy
On 26/04/15 13:44, Claude Warren wrote:
I see it as being very small but included in a lot of other test packages.
so for my mind it makes sense to put it into core or base. I think I am
partial to base as the code should not be RDF specific but would include
code to make nodes and triples. Given the nodes and triples creation I am
now thinking that core test is probably the best place for it.
I'm going to add a testing_framework package to the core test code. We can
move later as we see fit. I am also going to add a contract test for
graph. I'll create a branch to do that on.
Claude
On Sun, Apr 26, 2015 at 1:17 PM, Andy Seaborne <[email protected]> wrote:
Claude,
That's an advanced question :-)
How much base test helper code might there be?
If very small -> put it in jena-core src/test in it's own package.
If not very small, then it could even have it's own separate module, code
in src/main (which answers the "who tests the testing code" question!)
My intuitive reaction is that other modules will want to use the testing
code via jena-core - e.g. TDB wants to test it's implementation of Graph -
rather than the testign base code directly, but taht's just first reaction.
What do you see the options as being?
Andy
On 26/04/15 07:49, Claude Warren wrote:
So the base test helper code I was talking about yesterday -- do you see
this going into jena-base test branch? If I understand what you are
suggesting, I think I do.
Claude
On Sat, Apr 25, 2015 at 10:32 PM, 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
