Hi Aaron,
> With runnable jars, docker, kubernetes, etc, I have
> found deployment models that are much easier to manage than OSGi
> runtimes. All of which is to say: perhaps the Jena project should
> consider whether OSGi should be supported in the future.
Agreed. I can't recall when it was last mentioned on users@ and multiple
applications in the same JVM are not in fashion. I'd guess these systems
are unlikely to upgrade very frequently either.
We've said previously that OSGi was not one the main parts of Jena.
How about:
1/ Remove the OSGi convenience binaries, that is - apache-jena-osgi
jena-osgi and jena-osgi-features so that don't go to maven repo1.
https://repository.apache.org/content/repositories/orgapachejena-1044/org/apache/jena/
TIL: The Nexus repo let's us delete subtrees.
2/ Put in the announcement to users@ that there is no OSGi binaries in
this release due to late-emerging problems.
3/ Ask for any users to let us knowif they use the OSGi packaging.
In other words, leave the release source artifact (THE release) alone.
If necessary, someone can build from that, with fixes, and still be
using an official Jena release.
Absent anyone offering to help, we retire OSGi.
If there is sufficient demand, do 4.2.1 with fixed OSGi.
If you're happy to vote for the release with that plan - and so is
Bruno, who has voted - I will then test the proposed, revised maven tree
from an independent project.
This delays doing another build prior to 4.3.0 until we know whether it
is needed - whether OSGi (and know it's been confirmed as working) or
some other thing that emerges.
Andy
On 14/09/2021 14:38, Aaron Coburn wrote:
Hi Andy,
There are a few things that make OSGi provisioning difficult. Specifically,
the jena-osgi artifact (in its current form in 4.2.0-RC-1 and on the main
branch) includes the following Import-Package declarations:
com.apicatalog.jsonld,
com.apicatalog.jsonld.api,
com.apicatalog.jsonld.document,
com.apicatalog.rdf,
com.apicatalog.rdf.spi,
jakarta.json;version="[2.0,3)"
This requires the titanium and jakarta dependencies to be present. Those
dependencies are not present in Jena's features.xml configuration, though a
user could add those bundles separately. Unfortunately, the Titanium
dependencies are not OSGi bundles, so they cannot be added directly. In
Apache Karaf, there is a mechanism by which one can "wrap" a non-OSGi
bundle, but this does not work with Titanium. I am not entirely sure why it
doesn't work, but I suspect that it is an upstream issue that should be
sorted out with the titanium project (I will pursue that separately). There
is no particular difficulty installing the jakarta.json bundle, but that is
only needed when Titanium is present. By setting those dependencies as
optional (as is done in that PR), a user who does not use those features
will not need to have those dependencies present. And given that Titanium
doesn't appear to work in OSGi, an OSGi user will likely not be using
Titanium.
I will add, though, that I have more or less given up on working with OSGi
-- it presents a lot of challenges that can be hard to sort out (as you can
see based on this thread). Plus, in my opinion, many of the advantages of
OSGi are relevant only in servers where multiple applications exist in a
shared JVM runtime. With runnable jars, docker, kubernetes, etc, I have
found deployment models that are much easier to manage than OSGi runtimes.
All of which is to say: perhaps the Jena project should consider whether
OSGi should be supported in the future.
-Aaron
On Tue, 14 Sept 2021 at 05:47, Andy Seaborne <a...@apache.org> wrote:
On 14/09/2021 01:18, Aaron Coburn wrote:
...
I did find that the OSGi deployment failed on the new Titanium
dependencies. I have submitted a PR that fixes this:
https://github.com/apache/jena/pull/1072
Hi Aaron,
Not being an OSGi user, I have some simple questions:
What's the issue here? (what actually goes wrong - the PR says
installing Jena in an OSGi runtime is difficult - does that mean
impossible?)
Is it with Titanium or the jakarta dependencies?
If it's Titanium, is there something to ask for upstream?
Andy
