Github user asfgit closed the pull request at:
https://github.com/apache/jena/pull/10
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
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
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)
Yes longer term (and now we have moved to Java 7) it would be best to
avoid dynamic class loading where possible and use the Java 7
ServiceLoader paradigm instead.
Some of the existing stuff is because of the existing module structure
meaning that it is actually preferable to use the ARQ
First of all, I don't know if you are testing mine or Mark's bundle..
I'll assume mine from
http://repository.mygrid.org.uk/artifactory/ext-snapshot-local/org/apache/jena/jena-osgi/2.12.2-SNAPSHOT/jena-osgi-2.12.2-20141101.003350-4.jar
I stated in my longer email
Ah, exactly.. so say your jena-arq bundle does not depend on the
jena-core bundle at runtime, but simply embeds all of jena-arq AND
jena-core classes. So if both bundles are loaded at the same time..
troubles arise.
I think we really need to do something about these
intra-dependencies.. it is
So in your approach you will not use the OSGi bundles of httpclient, slf4j etc.
Are we sure they don't 'leak' out through any of the APIs?
On 4 November 2014 18:58, Mark Feblowitz markfeblow...@icloud.com wrote:
Basically, I’ve been including everything:
Manifest-Version: 1.0
Restructuring is certainly the way to go in the case of ARQ modifying
core. The simple solution is merge the codebases then restructure at
leisure, and that isn't a Jena3 issue.
What is the experience of ServiceLoader and how does it (and
META-INF/services/) interact with OSGi?
On Wed, Nov 5, 2014 at 10:45 AM, Rob Vesse rve...@dotnetrdf.org wrote:
Yes longer term (and now we have moved to Java 7) it would be best to
avoid dynamic class loading where possible and use the Java 7
ServiceLoader paradigm instead.
Some of the existing stuff is because of the existing
What I (still) don't understand is the use case for separate bundles per
separate jena module. (not that I'm an OSGi user ATM)
The contract around a Jena release is that the whole thing works
together. There aren't independent releases of ARQ and core, say. It
has been done as independent
We've been using ServiceLoader together with OSGi in taverna-scufl2.
You have to kind of allow your application to do both: e.g. you can
have setters and getters that can be injected in with OSGi Spring
services - and then if they have not been set (null), populate with
service loader.
The main reasons I see for keeping separate modules:
a) Version independence - A moves at a different pace than B, say B
v2.0 break things for users of B v.1.3 - while A v1.4 users should not
care.
b) Dependency requirements - A requires significantly different set of
dependencies than B - e.g.
On 05/11/14 12:36, Stian Soiland-Reyes wrote:
The main reasons I see for keeping separate modules:
Good list - let me see
a) Version independence - A moves at a different pace than B, say B
v2.0 break things for users of B v.1.3 - while A v1.4 users should not
care.
No longer happens for
Right.. then I think the httpclient and friends needs to be used as an
OSGi dependency (as my patch suggested) so that the client can access
it (and override their version), otherwise you get the classical
HttpClient is not an HttpClient classloader problem.
On 5 November 2014 12:34, Andy
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 -
We have these as separate bundles. I’ll be looking for potential leakage
issues.
Mark
On Nov 5, 2014, at 5:55 AM, Stian Soiland-Reyes
soiland-re...@cs.manchester.ac.uk wrote:
So in your approach you will not use the OSGi bundles of httpclient, slf4j
etc.
Are we sure they don't
As a consumer, I have no trouble having a single, potentially larger than
necessary bundle, rather than several that I have to manage. And when it comes
time for an upgrade, I’m happy to know that I don’t have to dedicate a portion
of a day figuring out what needs to be removed, to prevent
Hi
In the clerezza project we have been wrapping jena for a while as OSGi
bundles.
Recently it got split up into different bundles. The source (i.e. the poms)
can be seen here:
https://github.com/apache/clerezza/tree/master/ext
Cheers,
Reto
On Sat, Nov 1, 2014 at 2:26 AM, Stian Soiland-Reyes
Reto, what was the reason for why Clerezza made the
clerezza.osgi.dynamicimport.pkg indirect properties?
Not sure I quite get this property:
clerezza.osgi.export${clerezza.osgi.export.pkg}*;version=${pkgVersion};-split-package:=merge-first
/clerezza.osgi.export
On 4 November 2014 13:12,
If you found that splitting it up into different bundles works, then
perhaps we should not need to have any wrapping bundles at all, and
can just add the packagingbundle/packaging stuff to the main
modules?
On 4 November 2014 10:54, Reto Gmür r...@apache.org wrote:
Hi
In the clerezza project
Hi Stian,
If I understood and remember correctly the problem are circular
dependencies between jena artifacts and packages occurring in multiple
jars. I'm sure Minto (CC) can tell you the reasons more.
If providing OSGi bundles becomes part of Jena then maybe the root cause of
requiring this
Hi,
If I recall correctly it is required due Jena using dynamic class
loading (Class.forName). Doing a grep on my not updated in a long time
checkout reveals 38 occurrences.
If Jena is considering to provide OSGi bundles maybe then reconsider
using an alternative for dynamic class loading.
Basically, I’ve been including everything:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Jena
Bundle-SymbolicName: jena
Bundle-Version: 2.11.1.0
Bundle-Vendor: IBM repackage of apache-jena
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Import-Package: org.osgi.framework
In looking at the posted OSGi bundle I notice some items that we decided not to
include in ours:
xercesImpl-2.11.0.jar
xml-apis-1.4.01.jar
For reasons having to do with differences between Oracle Java and IBM Java, and
also issues with development on Macs, we decided to have
In looking at the posted OSGi bundle I notice some items that we decided not to
include in ours:
xercesImpl-2.11.0.jar
xml-apis-1.4.01.jar
For reasons having to do with differences between Oracle Java and IBM Java, and
also issues with development on Macs, we decided to have
On 28/10/14 16:50, stain wrote:
GitHub user stain opened a pull request:
https://github.com/apache/jena/pull/10
Jena OSGi bundle
Embedding core Jena modules in a single OSGi bundle.
This works around classloader issues such as Jena's use of
`Class.forName()`, but does
I’m an OSGi user, and have been using a custom-wrapped Jena OSGi bundle for
more than a year.
I’d be happy to try it out. How would I do so?
Mark
On Oct 31, 2014, at 6:56 AM, Andy Seaborne a...@apache.org wrote:
On 28/10/14 16:50, stain wrote:
GitHub user stain opened a pull request:
I’m an OSGi user, and have been using a custom-wrapped Jena OSGi bundle for
more than a year.
I’d be happy to try it out. How would I do so?
Mark
On Oct 31, 2014, at 6:56 AM, Andy Seaborne a...@apache.org wrote:
On 28/10/14 16:50, stain wrote:
GitHub user stain opened a pull request:
I would like to hear from your experience of a custom-wrapped bundle
what you decided to include or not.
See my other email message in this thread..
Basically in short:
http://build.mygrid.org.uk/ci/job/jena-bundle/21/org.apache.jena$jena-osgi/
GitHub user stain opened a pull request:
https://github.com/apache/jena/pull/10
Jena OSGi bundle
Embedding core Jena modules in a single OSGi bundle.
This works around classloader issues such as Jena's use of
`Class.forName()`, but does not yet support other OSGi bundles
30 matches
Mail list logo
