So what is then the difference from jena-base and jena-core? The base is utillity non-RDF stuff, and jena-core basic RDF? Would not jena-iri fit in jena-base?
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
