I know there is some testing code that manages reading from jars. This allows us to read the standard testing files from the test jars as stored in the maven repository. I am not certain if this is a different side of the same issue as the file:// issue but the jar/zip issue looks for bang (!) in the path name to use a zipInput stream.
Where would we put code like that? I think that the ability to read data files from a zip/jar would be a GIBNI (Gee, i'd be need it). Claude On Sun, Apr 26, 2015 at 2:07 PM, Andy Seaborne <[email protected]> wrote: > 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 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
