So I have updated the jena-osgi pull request in https://github.com/apache/jena/pull/10/
As commented there - it now includes a new module jena-osgi-test to test it within Equinox and Apache Felix (two of the leading OSGi frameworks). The tests are run as part of the maven build - any failure would be propagated out. It has to be in a separate module in order to test calling from 'another' OSGi module. Note that the test depends on the maven plugin https://github.com/everit-org/eosgi-maven-plugin This is licensed under LGPL. This is only used during the test/build (of jena-osgi-test) - which I believe should be acceptable according to: https://www.apache.org/legal/resolved.html#prohibited Given these brief tests working (which cover jena-core, jena-arq and jena-tdb), I would be comfortable to put it in, then wait for feedback. Perhaps wait with promoting it on the website before we know it works generally? I tried putting it into Clerezza instead of their org.apache.clerezza.ext.jena.* modules, but I am not knowledgeable enough about how to get Clerezza started as an OSGi application.. If you want to copy-paste it into a running OSGi setup, then have a look in jena/jena-osgi-test/target/eosgi-dist/felix/lib as it would contain the bundles you need. Namely: commons-csv-1.0.jar commons-lang3-3.3.2.jar httpclient-osgi-4.2.6.jar httpcore-osgi-4.2.5.jar jackson-annotations-2.3.0.jar jackson-core-2.3.3.jar jackson-databind-2.3.3.jar jcl-over-slf4j-1.7.6.jar jena-osgi-2.12.2-SNAPSHOT.jar jsonld-java-0.5.1.jar libthrift-0.9.2.jar log4j-1.2.17.jar slf4j-api-1.7.6.jar You might not want this if you do slf4j in another way: slf4j-log4j12-1.7.6.jar You should not need these as they are only used for the testing: org.ops4j.pax.tipi.junit-4.11.0.1.jar jena-osgi-test-2.12.2-SNAPSHOT.jar org.everit.osgi.dev.testrunner-4.0.3.jar org.everit.osgi.dev.testrunner.junit4-3.0.4.jar org.ops4j.pax.tipi.hamcrest.core-1.3.0.1.jar On 7 January 2015 at 11:45, Stian Soiland-Reyes <st...@apache.org> wrote: > I'm not (yet) an expert in OSGi, I'm just trying to get the wheels spinning.. > :) > > > These legacy bits are a bit trickier: > > ./jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/RDFReaderFImpl.java: > return (RDFReader) Class.forName(className) > ./jena-core/src/main/java/com/hp/hpl/jena/rdf/model/impl/RDFWriterFImpl.java: > return (RDFWriter) Class.forName(className).newInstance(); > ./jena-core/src/main/java/com/hp/hpl/jena/ontology/impl/OntModelImpl.java: > owlSyntaxCheckerClass = > Class.forName(owlSyntaxCheckerClassName); > > > .. specially as jena-arq RIOT registers its replacement readers and > writers by classname. > > That is what IMHO is preventing each jena-* submodule to be > independent OSGi bundles. > > It should be possible to fix these by passing in the actual Class > instead (with a deprecated method for the String className). > > > But the jena-osgi solution should in theory work well, by basically > shadowing in jena-arq, jena-core, jena-tdb and jena-iri to the same > bundle. > > I'll have another go to update my pull request - sorry for letting > this slip earlier. Now that we use the bundle version of jsonld-java > (0.5.1) it looks a bit cleaner as well. > > > > > > On 7 January 2015 at 11:10, Andy Seaborne <a...@apache.org> wrote: >> Where are we on this item? >> >> Must be time soon for the next Jena release and getting this in as an >> addition binary artifact would be excellent. As ever, getting feedback >> before releases is slow so a way forward is to include a new binary >> artifact, expecting to iterate it a bit. >> >> A quick look for Class.forName, many are irrelevant (SDB, Fuseki1, testing). >> >> I don't use OSGi so I'm looking/hoping/needing an expert who will sprinkle >> the techno-fairy dust. >> >> Andy > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating) > http://orcid.org/0000-0001-9842-9718 -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/0000-0001-9842-9718
