+1 Claude
I liked the idea of having some common testing code in one place, and I'm also
leaning toward having it in base later.
Bruno
From: Claude Warren <cla...@xenei.com>
To: dev@jena.apache.org
Sent: Monday, April 27, 2015 12:44 AM
Subject: Re: New module : jena-base
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 <a...@apache.org> 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 <a...@apache.org> 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
>>>
>>>
>>
>>
>>
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
