Last time I looked at interdependencies there were several Class.forName() calls around in jena-core and jena-arq - see https://paste.apache.org/5y0W
Class.forName() depends on the ClassLoader of the caller (by introspecting the call stack) - but in OSGi there are multiple ClassLoaders, think of it as one per JAR - and they can only access packages that are declared as Imports in their META-INF/MANIFEST.MF This would falls apart if the class to be called is not explicitly included in the OSGi imports. Some of these were for instance with jena-arq parsers and writers registering themselves with classname in jena-core - but jena-core can't access jena-arq classes in OSGi (Although circular imports are technically allowed in OSGi it's not usually a good idea). Now we have Jena 3, but we still have the duplication between RDFReaderFImpl in jena-core and IO_JenaReaders in jena-arq - so this is very much a real problem, because using riot would autoregister its classnames in RDFReaderFImp. Third-party callers could also be registering - although RDFReaderFImp is screaming "imp imp" all over the place, so we should be free to change that. Such registrations should instead by done with the java.lang.Class parameters - which can then be used directly. The On 10 September 2015 at 22:50, Stian Soiland-Reyes <[email protected]> wrote: > On 10 September 2015 at 18:13, [email protected] <[email protected]> wrote: >> If this is a matter of "just a couple of lines in the manifest file" cannot >> a patch be created to do that in Jena itself? Are there inter-module >> dependency issues that make that difficult? > > > In theory just setting > > <packaging>bundle</packaging> > > and using the maven-bundle-plugin > is enough to auto-generate the correct META-INF metadata for OSGi. > This can be customized (as we do for the apache-jena-osgi/jena-osgi > module). > > One complication is if the external dependencies are OSGi or not - > httpclient is one tricky one as it has done the same as Jena and > provided a separate wrapper httpclient-osgi (and httpcore-osgi) - > however the way they did this with Maven means that just using it as a > dependency would still pull in a dependency on the regular httpclient > library. So if you are a non-OSGi user you would then see the > httpclient classes in two JARs - which with Maven version resolution > could easily become in mismatched versions. > > Ironically httpclient-osgi does not depend on httpcore-osgi - so the > one dependency that it truly need isn't stated in its pom. > > > In jena-osgi I therefore excluded all those deeper dependencies: > > See > https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-osgi/pom.xml#L165 > > To avoid Jena-Maven-OSGi users the same issue, I similarly here > slightly misused the <scope>provided</scope> for the dependencies that > are not to be dependencies of the final jena-osgi JAR, but which are > shadowed inside. > https://github.com/apache/jena/blob/master/apache-jena-osgi/jena-osgi/pom.xml#L107 > > > If we move to <packaging>bundle</packaging> then we should get > httpclient folks to sort out their poms upstream so we can rely on > them in a cleaner fashion across Jena. (or put this exclusion rule > into <dependencyManagement> of jena-parent) - I don't think > copy-pasting that big <exclusion> block around anything that directly > or indirectly requires things like httpclient is good. > > Ideally they should also move to <packaging>bundle</packaging> and > avoid *-osgi, which would of course simplify things. > > > There are other potential issues as Class.forName() which the current > jena-osgi is narrowly cheating around by effectively making a single > class loader for all of Jena (including as Reto pointed out, TDB etc) > > > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating), Apache Commons RDF (incubating) > http://orcid.org/0000-0001-9842-9718 -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
