Make JSON imports optional in OSGi environments #3971
Conversation
When deploying in OSGi containers the Jedis bundle has two hard requirements on having the GSON and JSON bundles around. Since these depenendencies are optional we mark the imports as such in the OSGi manifest. If these packages are not exported the bundle will be installed and will be unable to make use of the JSON functionality. When they are present they will be used. Additionally, allow newer version of the org.json bundle to be used without requiring a new release of Jedis.
rombert
force-pushed
the
feature/optional-json-imports-osgi
branch
from
81d4678
to
e4d5aa4
Compare
| --> | ||
| <Import-Package> | ||
| com.google.gson;resolution:=optional, | ||
| org.json;resolution:=optional;version="20240303.0", |
There was a problem hiding this comment.
This indicates a fixed version. Does this mean whenever we update the version of org.json, we'd have to change here as well?
There was a problem hiding this comment.
My understanding is that this is an open range - ["20240303.0", Infinity). I'll dig up some references to it and post some screenshots of it working with different versions.
There was a problem hiding this comment.
According to https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3189032
If a version range is specified as a single version, it must be interpreted as the range [version,∞).
So this means just a minimal version. Right now org.json does not have a version newer that 20240303, but I will update the bundle locally to accept older versions for org.json so I can post a test with exact match and one with a newer version.
There was a problem hiding this comment.
Here's a more explicit test. I modified the Jedis bundle locally to reference a lower import range
diff --git a/pom.xml b/pom.xml
index f929411d..415273d4 100644
--- a/pom.xml
+++ b/pom.xml
@@ -300,7 +300,7 @@
-->
<Import-Package>
com.google.gson;resolution:=optional,
- org.json;resolution:=optional;version="20240303.0",
+ org.json;resolution:=optional;version="20220303.0",
*
</Import-Package>
</instructions>
I then deployed it in my OSGi app and kept the same (new) 20240303 org.json bundle. In the screenshot you can see that the import is resolved at runtime with the new 20240303.0 version, even though the Import-Package declaration references 20220303.0 .
Effectively all versions newer than 20240303.0 are supported. If you want me I can lower the import range if you think that older versions can be used. Otherwise I'm happy to leave this as it is.
There was a problem hiding this comment.
Thank you @rombert for your investigation. It'll be helpful for us.
|
I was wondering: if we are able to use the Jedis driver without these two - shouldn't we mark them as optional in the Maven dependency tree too. If we do then the |
Yes, if the Maven dependencies are marked as optional the maven-bundle-plugin should also make the imports optional. The version pinning for the org.json import, if deemed acceptable, still needs to stay. |
Yes, but this is a breaking change and has been considered as unfavorable #3278 |
Apologies, was not aware of #3278, makes sense. In this case, for OSGi specifically, this seems a reasonable improvement. AFAIK most (all?) OSGi containers depend on the user to deploy the artefacts (e.g. by using a WAR file or a nested JAR file or some other way) and the MANIFEST.MF only serves to mandate what should be loaded, so we should not have the same issues as the ones described in #3278 |
Yes, that is correct. In the current form of Jedis the two JSON bundles must be deployed, even if they are not used by the application. |
When deploying in OSGi containers the Jedis bundle has two hard requirements on having the GSON and JSON bundles around. Since these depenendencies are optional we mark the imports as such in the OSGi manifest.
If these packages are not exported the bundle will be installed and will be unable to make use of the JSON functionality. When they are present they will be used.
Additionally, allow newer version of the org.json bundle to be used without requiring a new release of Jedis.
Fixes #3956 .