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
Few issues around of OSGi-specific headers in manifests #678
Comments
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. |
Here are some resources I planned to explore when available. Wish them help! |
Signed-off-by: Fabian Stäber <fabian@fstab.de>
I changed the packaging of For "2: Make packages optional" I would need a PR or further help. I could throw a configuration like this into the <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. |
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! |
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 |
Any progress on this issue? |
Should be fixed by #790. |
I'm glad to see most artifacts of this project are packed as bundles, while I find some little glitches as listed below.
simpleclient_tracer_*
are not packed as bundles while other bundles likesimpleclient
itself import packages from them, which fails the startup of OSGi runtime.The text was updated successfully, but these errors were encountered: