> There is some argument for > > jena-ogsi-core = iri+core+arq > > and no TDB.
OK, perhaps that is right. I only reflected what was in the distro - I must admit I have poor understanding of what TDB and SDB is and when they would be used :-( But if we exclude jena-tdb and jena-sdb from jena-osgi - then what about OSGi users who need those? jena-tdb-osgi etc? Or do we make them native osgi bundles? I believe it is simpler if Jena is either fully OSGified (e.g. every module is a bundle, and we sort out the class.forName() issues) - or that there is a single jena-osgi module. A hybrid approach requires mirroring of every module that is to be OSGified - and increases the risk of duplicates - as in the clerezza approach. With time I can try to help with sorting out the services/classforname-thingies - but it requires a fair bit of digging and testing. For instance RDFReaderFImpl.getReader(String lang) in core reads a map of langToClassName registered with setBaseReaderClassName. We can make setBaseReaderClassName deprecated, and add setBaseReaderClass(String lang, Class readerClass) and instead keep a map of the actual classes. The original method can use a few tricks to try to resolve the class from the registering method (e.g. contextclassloader, or as Class.forName does with looking two steps up the stack frame (!)). >> c) Separation of concern - A is the API, B is the implementation. >> Almost nobody should use B directly. > Valuable if there are multiple independent implementations of A, otherwise > it's more internal/development style, I would say. Right, if using that approach, it would be more of a kind of double-lock - more applicable to larger projects with many modules. In my experience it is easy to take this too far :-( -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
