Few issues around of OSGi-specific headers in manifests

[bigmarvin]

I'm glad to see most artifacts of this project are packed as bundles, while I find some little glitches as listed below.

1. The artifacts of name simpleclient_tracer_* are not packed as bundles while other bundles like simpleclient itself import packages from them, which fails the startup of OSGi runtime.
2. The resolution of all imported packages is mandatory by default, but I doubt if every client would use every imported package every time. It's better to make them optional so the runtime knows which version of packages to look for when necessary and yet no startup is blocked.

[fstab]

Thanks for bringing this up. I've never looked into OSGI. Could you let me know a simple way to set up an OSGI project so that I could try this? Maybe I can turn it into an automated test.

[bigmarvin]

Here are some resources I planned to explore when available. Wish them help!

https://felix.apache.org/documentation/subprojects.html

[fstab]

I changed the packaging of simpleclient_tracer_* to bundle, which should solve your 1st point.

For "2: Make packages optional" I would need a PR or further help. I could throw a configuration like this into the pom.xml

<plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <version>2.4.0</version>
    <extensions>true</extensions>
    <configuration>
        <instructions>
            <Import-Package>
                *;resolution=optional
            </Import-Package>
        </instructions>
    </configuration>
</plugin>

However, I don't know what the implications are. I guess some things are not optional, so it might break something. I don't have much experience with OSGI.

[bigmarvin]

Thanks for addressing the 1st part! Let me try to illustrate the 2nd part as following.

The primary advantage of OSGi would be enabling same class of different versions co-work properly in one JVM. It's achieved by building the topology of versioned packages provided/required by bundles (called wiring).

During the start-up of OSGi runtime, it would check if this topology can be built or not. If some package required by some bundle is mandatory while no bundle can provide it, the start-up would fail. That's what I ran into in the first place. If the required package is optional, on the other hand, the start-up won't fail at this phase at least.

Optional resolution is handy when, say some classes under some target package integrate with many partners or so (e.g. some middleware integrating with all kinds of JMS implementation). However, as some client of this target package, it would only integrate with one or few partners in real world. If the packages of all partners are mandatorily required, the client must also include all package providers in the runtime for wiring to work but effectively most of them would be never used. If the resolution is optional, such massive inclusion wouldn't be necessary.

The drawback would be, however, if the packages of some partner in use are absent, e.g. not provided by any bundle, the start-up would still fail when the client bundle tries to load some class using that partner in the target package. Though postponed from wiring phase to activating phase, this error is expected and can be fixed by including the provider of these missing classes (usually some artifact of the partner). OSGi runtime would always use the info of import-package instructions to locate qualified packages regardless of its resolution, mandatory or optional.

Based on what I know, optional imported packages are OK for bundles without any resources at runtime (e.g. no OSGi service), because they don't really load any class by themselves. The client bundle is responsible to trigger the loading of the classes it uses, together with their dependencies, so it can make some packages mandatorily required to make sure its activation work.

Finally, it's correct to test every change, and this change can be tested by running OSGi runtime with some predefined combinations of artifacts, to make sure some regular use scenarios are supported. However, this isn't trivial as you may have tried.

Wish it help!

[hdost]

Having had some work with OSGi in the past (granted it's been a few years now), and from your explanation I am curious why the focus is on these particular libraries for the second part because as far as I can tell all them would be useless without the OpenTelemetry APIs so the bundles upstream of this, so the ones depending on simpleclient_tracer_otel* should make them optional and in fact these libraries. That would fix your issue with providing them wouldn't it?
A: Some App
B: One of the Simple Client Tracer Libs
C: OpenTelemetry Lib
A ----(optional) ----> B ---(mandatory)---> C
"A" should be able to start up no problem without it, no?

[iskandergaba]

Any progress on this issue?

[fstab]

Should be fixed by #790.