Repository navigation
Add support for OSGI bundles #414
Description
There are classes used from Gson internal API
com.google.gson.internal.Streams is used in com/microsoft/graph/serializer/ODataTypeParametrizedIJsonBackedTypedAdapter.java
com.google.gson.internal.bind.ReflectiveTypeAdapterFactory is used in com/microsoft/graph/serializer/FallbackTypeAdapterFactory.java
This is also the reason why this library cannot be used in the OSGI environment as starting from Gson 2.6, the com.google.gson.internal packages are no longer exported in the OSGi bundles.
Activity
baywet commentedon Jan 19, 2022
Hi martmoldau
Thanks for reaching out.
FYI we're working on an overhaul of the Java SDK by switching it to our newest generator kiota. This effort will take time, and you should see previews for that newer version in the next few months.
Part of that effort includes changes in the way serialization/deserialization is handled to avoid a strong dependency on any given serialization format/library and allow people to easily replace the implementation should they want to.
We've already had one request for OSGI in the past, could you expand on what scenario it'd unlock for you? what environments are you trying to build a solution for? Thanks!
martmoldau commentedon Jan 19, 2022
Hi Vincent Biret (@baywet)
Solution I'm working on is integration between different systems including different parts from Microsoft O365. This is based on Apache Camel which runs in OSGI environment Apache Karaf. There are ready made enterprise integration platforms also built on top of these. Red Hat Fuse or Talend for an example.
MS Graph API is a big step forward when one has to interface with different parts from MS Cloud. Right now getting it going under the OSGI is quite a hassle as OSGI's classloading is very strict. I had to customise gson package manifest to get around this problem and also a lot of guesswork to explain what packages MS Grapi API needs to import. But it is still worth it. Keep up the good work!
About the OSGI request you were referring. Actually it's still same jar packaging as now. OSGI needs more detailed manifest and that is a task all the build tools can do I guess. I would vote for it:)
baywet commentedon Jan 20, 2022
Thanks for the additional information.
So, if I understand things properly:
Now, here come the questions where I'm still fuzzy on the details:
martmoldau commentedon Jan 20, 2022
You understood and described things in the first section quite right. Adding manifest properties is actually only reason why they are not OSGI bundles. Adding those properties to manifest will make it OSGI ready, but then it wants to import gson internal classes and this fails because gson OSGI bundle has those internal classes, but for internal use only.
It's not mandatory to create or export any services. Services can be useful when one starts to build some solution specially for OSGI environment, but for a regular java library this is usually not the case. Good enough is when there are package name, description, version, imports and exports listed in the manifest. Imports can be mandatory or optional and also version or version range can be specified e.g. gson >=2.6 and < 3.0.
Dependecies don't need to be OSGI bundles. For a user it is convinient when they are, but adding this extra info into manifest is up to each library maintainer not yours. There can be even different packaging for the same library. for example Kotlin has put together their different libraries into separately packaged kotlin-osgi-bundle.
In current ms-graph api dependencies there where only two without OSGI support; com.squareup.okhttp3 and com.squareup.okio if I recall it right. This is usually not a problem when this kind of package has only few dependencies, but can be a headache when there are lot of depencies. Bndtools can be useful in those cases, It scans the code for the imported classes, but cannot help with required library versions or when dynamic classloading is used and this is case with this library too.
11 remaining items
martmoldau commentedon Jan 27, 2022
Thank you, Vincent Biret (@baywet), too!
My workaround was to customize gson's package manifest to export the internal packages too, but as this is not a recommended practice I prefer not to share the details here.
If one decides to follow my path around gson and installing ms-graph 5.11.0 and ms-graph-core 2.0.10 on Karaf OSGI then following might help a bit:
There might be more dependencies needed depending what parts of graph api will be used. In my case it is mostly reading-writing Sharepoint Online lists and Termstore(managed metadata).
baywet commentedon Jan 27, 2022
thanks for sharing that additional information with the broader community!
baywet commentedon Mar 31, 2022
To provide additional context on that we're working on a migration to our new SDK generator kiota, this is going to take a while, but part of doing that work will remove a dependency on those internal classes which should unlock that aspect. Version number for core will be 3.X when it reaches preview.
We're not doing any work to remove those dependencies on the current major version of core (2.X) because that'd mean breaking current functionality.
maisarissi commentedon Mar 10, 2023
Adobe have also shown interest for OSGI support in the Java SDK.
As mentioned before, OSGI support will be added as part of the core 3.X.
We will consider this feature as part of CY23H2 (2023 second half-year) planning.