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
