Add OSGi support for API and SDK

[Sandared]

It would be awesome if ot api and sdk could provide manifests with proper OSGi entries, e.g., by using the bnd gradle plugin that calculates them automatically :)

[LWogan]

Added a PR to do this here:
#4627

[royteeuwen]

Could you give input if this is feasible? We also want to include opentelemetry into an OSGi application and would love to have the osgi manifest headers available

[jkwatson]

None of the maintainers are very familiar with OSGI, so your best bet is a contribution at this point.

[royteeuwen]

@jkwatson I have created a very basic PR that adds OSGi support. It only adds a gradle plugin that automatically sets the correct headers and added the exportcontents manifest so that every package is available for OSGi usage. How can we get this merged :)?

[jkwatson]

@jkwatson I have created a very basic PR that adds OSGi support. It only adds a gradle plugin that automatically sets the correct headers and added the exportcontents manifest so that every package is available for OSGi usage. How can we get this merged :)?

Hi @royteeuwen . I noticed the PR. We're looking for someone (anyone!) who knows something about OSGi to help review this. Post xz, you can understand how we're a bit cautious about accepting changes to our build process from people who have not been active in the community, with plugins that none of us are familiar with.

Would you be able to attend one of our weekly Java SIG meetings to help us get to know you and feel comfortable with the addition to the build process?

[bdhoine]

@jkwatson I also added a commit and opened a PR to semcov (open-telemetry/semantic-conventions-java#87) to achieve the same and I'm also working on opening a PR on the libraries. If you would like me to join also feel free reach out.

[royteeuwen]

@jkwatson of course! I'm an Apache committer myself (royteeuwen: https://people.apache.org/committer-index.html#R)

I also have some other open source projects under my organisation name Orbinson:
https://github.com/orbinson

@bdhoine and myself are also hosting a session at a conference, specifically highlighting all capabilities of OpenTelemetry in AEM, which is a platform that is built upon OSGi:

https://adapt.to/2024/schedule/observability-in-aemaacs-with-opentelemetry

There are enough other OSGi based platforms that would benefit a lot of having things, I can name some if it is of interest.

Just shout how I can join the Java SIG and I'll join to give an intro of myself and what the PR does

[jkwatson]

Meeting info can be found here: https://github.com/open-telemetry/community?tab=readme-ov-file#implementation-sigs

[jkwatson]

@royteeuwen have you had a chance to test the resulting artifacts from this change? Concerns were expressed offline about whether you need to consider the internal classes as well, since they are used, but not intended for public consumption.

[royteeuwen]

@jkwatson we came to the same conclusions yesterday, that internal isn't really internal to that specific jar 😅

Exposing the api and context jar's as OSGi bundles are the easiest and we already got that working, so I might do it in two phases, one for the consumer of the api's that can use the java agent as configurator, and then another PR for the SDK jars, that have transitive deps like okhttp that also might need a fix. Does that sound OK for you? I will make an integration test for both situations

[brianmituka]

Hi, is there an update on this? I am interested in integrating open-telemetry in an OSGI environment and I came across this thread.

[royteeuwen]

I am waiting for the release of bnd plugin 7.1.0, this will make it a lot easier to integrate OSGi manifest headers into libraries that use the java ServiceLoader principle. It will auto-detect it and then generate the correct headers instead of having to manually specify them in the wrappers I "handmade" like here:

https://github.com/orbinson/opentelemetry-osgi-wrappers/blob/main/opentelemetry-java/opentelemetry-exporter-otlp/pom.xml#L39

Ideally we can get rid of the handmade wrappers, by showcasing how it works in OSGi and by having the headers generated in this project. I already have this done in the referenced maven project, but will have to migrate this to gradle and add an integration test in this projects PR