You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2015/01/07 12:10:31 UTC
Re: [GitHub] jena pull request: Jena OSGi bundle
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
Re: [GitHub] jena pull request: Jena OSGi bundle
Posted by Stian Soiland-Reyes <st...@apache.org>.
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 <an...@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
Re: [GitHub] jena pull request: Jena OSGi bundle
Posted by Stian Soiland-Reyes <st...@apache.org>.
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 <an...@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