Add initial OSGi support

[jack-berg]

Related to #768.

This adds initial OSGi support to all artifacts. Specifically, this uses the biz.aQute.bnd.builder plugin to enrich each artifact's MANIFEST.MF. Here's a before and after of MANIFEST.MF for opentelemetry-api:

Before:

Manifest-Version: 1.0
Automatic-Module-Name: io.opentelemetry.api
Built-By: jberg
Built-JDK: 21.0.8
Implementation-Title: all
Implementation-Version: 1.57.0-SNAPSHOT

After:

Manifest-Version: 1.0
Automatic-Module-Name: io.opentelemetry.api
Built-By: jberg
Built-JDK: 21.0.8
Bundle-ManifestVersion: 2
Bundle-Name: opentelemetry-api
Bundle-SymbolicName: opentelemetry-api
Bundle-Version: 1.58.0.SNAPSHOT
Created-By: 21.0.8 (Eclipse Adoptium)
Export-Package: io.opentelemetry.api;version="1.58.0";uses:="io.opente
 lemetry.api.logs,io.opentelemetry.api.metrics,io.opentelemetry.api.tr
 ace,io.opentelemetry.context.propagation",io.opentelemetry.api.baggag
 e;version="1.58.0";uses:="io.opentelemetry.context,javax.annotation",
 io.opentelemetry.api.baggage.propagation;version="1.58.0";uses:="io.o
 pentelemetry.context,io.opentelemetry.context.propagation,javax.annot
 ation",io.opentelemetry.api.common;version="1.58.0";uses:="javax.anno
 tation",io.opentelemetry.api.internal;version="1.58.0";uses:="io.open
 telemetry.api,io.opentelemetry.api.common,io.opentelemetry.api.trace,
 io.opentelemetry.context,javax.annotation",io.opentelemetry.api.logs;
 version="1.58.0";uses:="io.opentelemetry.api.common,io.opentelemetry.
 context,javax.annotation",io.opentelemetry.api.metrics;version="1.58.
 0";uses:="io.opentelemetry.api.common,io.opentelemetry.context",io.op
 entelemetry.api.trace;version="1.58.0";uses:="io.opentelemetry.api.co
 mmon,io.opentelemetry.context,javax.annotation",io.opentelemetry.api.
 trace.propagation;version="1.58.0";uses:="io.opentelemetry.context,io
 .opentelemetry.context.propagation,javax.annotation",io.opentelemetry
 .api.trace.propagation.internal;version="1.58.0";uses:="io.openteleme
 try.api.trace"
Implementation-Title: all
Implementation-Version: 1.58.0-SNAPSHOT
Import-Package: javax.annotation;version="[3.0,4)";resolution:=optiona
 l,io.opentelemetry.sdk.autoconfigure;resolution:=optional,io.opentele
 metry.api.incubator;resolution:=optional,io.opentelemetry.api.incubat
 or.internal;resolution:=optional,io.opentelemetry.context;version="[1
 .58,2)",io.opentelemetry.context.propagation;version="[1.58,2)",java.
 io,java.lang,java.lang.annotation,java.lang.invoke,java.lang.reflect,
 java.nio,java.nio.charset,java.time,java.util,java.util.concurrent,ja
 va.util.function,java.util.logging,java.util.regex,java.util.stream
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
Tool: Bnd-7.2.0.202512261929

The import thing this tool does is specify each artifact's Export-Package and Import-Package. Still coming up to speed on OSGi, but my understanding is that this is a specification for the packages each artifact exports for use by others, and the packages each depends on.

Ideally, we would exclude our *.internal.* packages from our exports, but this is blocked by #6970.

A key bit we have to do is tell OSGi which packages are optional. For example, opentelemetry-api has compileOnly dependencies on opentelemetry-api-incubator and a reflection interaction with opentelemetry-sdk-extension-autoconfigure. If we don't tell the bnd that these are optional, then OSGi environments fail to initialize when these are missing. I've extended our gradle tooling to make it easy to specify optional packages by setting otelJava.osgiOptionalPackages.

Detecting misconfiguration of OSGi around optional packages requires test configurations that exercise a specific set of dependencies. I have an initial test configuration which only includes opentelemetry-sdk and transitive dependencies, and have done an initial pass of specifying optional dependencies, but more test configurations and more OSGi configuration will be needed.

[jack-berg]

Would hugely appreciate if @stbischof / @roytee @royteeuwen could give this a sanity check!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (ca536b2) to head (3791990).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #7964   +/-   ##
=========================================
  Coverage     90.12%   90.12%           
  Complexity     7463     7463           
=========================================
  Files           834      834           
  Lines         22585    22585           
  Branches       2239     2239           
=========================================
  Hits          20354    20354           
  Misses         1530     1530           
  Partials        701      701           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[stbischof]

Will Look at this at weekend

@jack-berg you May want Thatcher BND also calc your jpms Module info.

https://bnd.bndtools.org/chapters/330-jpms.html

Maybe. Not on this Step and Pr. But this Couleur be an extra

[jack-berg]

@jack-berg you May want Thatcher BND also calc your jpms Module info.

Thanks for the tip! My approach is going to be to write a test case showing a scenario that fails, then update the bnd configuration so it passes. So the key will be knowing which scenarios fail without bnd calculating jpms module info, and encoding that into a test.

[royteeuwen]

Would hugely appreciate if @stbischof / @roytee could give this a sanity check!

@jack-berg I'm guessing you mean me instead of @roytee 😄 , but sure, will try and find some time in the coming week to test everything out :)!

What caused you to implement it ;)?

[jack-berg]

What caused you to implement it ;)?

Been meaning to for a while given how many 👍 the issue has. Was out on parental leave when this comment was left. Long overdue I gave it some attention!