Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OSGi support for API and SDK #768

Open
Sandared opened this issue Jan 17, 2020 · 12 comments
Open

Add OSGi support for API and SDK #768

Sandared opened this issue Jan 17, 2020 · 12 comments

Comments

@Sandared
Copy link

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
Copy link

LWogan commented Jul 19, 2022

Added a PR to do this here:
#4627

@royteeuwen
Copy link

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
Copy link
Contributor

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

royteeuwen pushed a commit to orbinson/opentelemetry-java that referenced this issue Aug 23, 2024
royteeuwen pushed a commit to orbinson/opentelemetry-java that referenced this issue Aug 23, 2024
royteeuwen added a commit to orbinson/opentelemetry-java that referenced this issue Aug 23, 2024
@royteeuwen
Copy link

@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
Copy link
Contributor

@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
Copy link

bdhoine commented Aug 25, 2024

@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
Copy link

royteeuwen commented Aug 25, 2024

@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
Copy link
Contributor

@jkwatson
Copy link
Contributor

@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
Copy link

@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
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants