GH-2043 make more imports optional of runtime-osgi

[kenwenzel]

GitHub issue resolved: #2043

Changed BND instructions to also make following imports optional:

• org.locationtech
• org.elasticsearch
• ch.qos.logback

[abrokenjester]

I have no real way to judge this as I have little expertise on OSGi. @manuelfiorelli I know you've used the OSGi bundle in the past, can you take a quick look at this PR and tell us if it makes sense?

Open questions I have:

1. is this change backwards-compatible for OSGi bundle users?
2. will it require any changes at the user end for current consumers of the OSGi bundle?

[manuelfiorelli]

Hi @jeenbroekstra. I looked at this PR without building the code by myself.
The first thing that I noticed is that the PR should actually do what it claims: just remove the 3 mentioned package imports. In fact, @kenwenzel also removed the the import of the packages org.eclipse.rdf4j.*, which are also exported by the bundle. This change should only affect users that deployed another bundle that exports these packages into the same container: in this case, the OSGi framework might force the rdf4j-runtime bundle to use the packages exported by the other bundle instead of its own versions.

In general, the main implication of removing a package import is the generation of exceptions when the JVM needs a class from that package. Since the JVM adopts a lazy loading strategy, these exceptions should be thrown only when the user tries to execute a portion of RDF4J that needs those classes:

• in case of org.locationtech, the portion should include the GeoSpatial modules
• in case of org.elasticsearch, the portion should be related to fulltext search
• regarding ch.qos.logback, I don't know which portion of RDF4J explicitly uses that logger library: in most cases, RDF4J should just use slf4j, completely the choice of a logging library to the user.

Summarizing, the consequences of this PR are mainly two:

• the user no longer needs bundles providing the packages org.locationtech and org.elasticsearch
• but, if the user actually hits portions of the runtime that exploit these packages, the JVM will throw some exceptions.

In other words, this PR goes into the direction of having an RDF4J runtime which can be configured (by supplying specific dependencies) to enable a subset of the modules.

Existing users shouldn't be affected by this PR.

[abrokenjester]

Excellent, thanks for your review @manuelfiorelli ! And @kenwenzel , thanks again for providing this patch!