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

Trying to wrap a non-OSGi jar using bnd, where the jar contains META-INF/services #6304

Closed
royteeuwen opened this issue Sep 28, 2024 · 13 comments

Comments

@royteeuwen
Copy link

I have a very simple pom.xml where I'm trying to wrap a non-OSGi jar using the bnd-maven-plugin where the only dependency of the pom is the non-osgi jar with exclusion of all dependencies. I've tried the following two approaches:

-includeresource: non-osgi-jar-*.jar;lib:=true

and

-conditionalpackage: *

But for both approaches, it does not generate the Provide-Capability headers for osgi.serviceloader;osgi.serviceloader

What would be the correct approach so that the bnd-maven-plugin detects that the embedded jar contains META-INF/services files and generate the correct headers in the osgi-wrapped bundle?

@chrisrueger
Copy link
Contributor

chrisrueger commented Sep 28, 2024

This issue #5912 and PR #5903 sound related. But sounds like the code of the jar need to be under your control.

I guess you could also add the header manually.

@royteeuwen
Copy link
Author

royteeuwen commented Sep 28, 2024

@chrisrueger of course, but that would mean that I have to always manually check when a version update occurs for the wrapped library if it contains ServiceLoader services file. If possible, I'd like to avoid it :)!

I'm also trying to figure out if the ServiceLoader provide-capability can actually be auto-generated and in what way

@chrisrueger
Copy link
Contributor

@chrisrueger of course, but that would mean that I have to always manually check when a version update occurs for the wrapped library if it contains ServiceLoader services file. If possible, I'd like to avoid it :)!

Yeah i should've have written that about the manual adding 😃, but wasn't sure how familiar you are with bnd so i thought i mention it.

Anyway, the topic is not my expertise. Let's wait if there is anybody else.

@royteeuwen
Copy link
Author

👍 thanks for checking in any case! So far I have only found a gradle example, where it's at least sort of automated, it checks if any file exists in the META-INF/services and then creates the osgi headers for those, without explicitely naming which ones it are: https://github.com/apache/groovy/blob/master/build-logic/src/main/groovy/org.apache.groovy-library.gradle#L41

Hoping to find a (semi) automated manner with maven as well 😄

@pkriens
Copy link
Member

pkriens commented Oct 2, 2024

-includeresource @non-osgi-jar.jar

This will unroll your jar into the new jar. This will include the manifest but this gets updated. Although I am not sure the capability gets updated? This is normally created via the annotation?

@royteeuwen
Copy link
Author

@pkriens thats indeed the point, it is a non-osgi-jar, so it doesn't have the bnd annotations, it is not aware of OSGi in any way. So I'm searching for a way to make the non-osgi automatically have the correct capability headers purely based on the META-INF/services folder, and not any OSGi / bnd specific annotations

@chrisrueger
Copy link
Contributor

chrisrueger commented Oct 2, 2024

it is a non-osgi-jar, so it doesn't have the bnd annotations, it is not aware of OSGi in any way. So I'm searching for a way to make the non-osgi automatically have the correct capability headers purely based on the META-INF/services folder, and not any OSGi / bnd specific annotations

I had a look at your gradle example and then posted this question in the forum to basically replicate the gradle approach with bnd macros. But it seems there is no macro to achieve that.

@pkriens how would you approach this generally? A macro based approach like my forum question? or a new bnd instruction? or none of it at all? I don't know how corner case-ish this is.

Based on the answer you @royteeuwen are welcome to create a PR. I could assist you setting up the dev environment if needed.

@royteeuwen
Copy link
Author

royteeuwen commented Oct 2, 2024

thanks for the effort @chrisrueger ! and I'm indeed eager at the answer if this is viable and wanted in bnd, I have been doing a lot of OSGi wrapping of bundles in my past 10 years and the last years I've been seeing the service loader approach more and more.

Just FYI, the jars I'm actually trying to wrap are the OpenTelemetry Java jars, they use the ServiceLoader principle:
https://github.com/open-telemetry/opentelemetry-java/tree/main/exporters/otlp/all/src/main/resources/META-INF/services

here are my wrapper (still using the old maven-bundle-plugin, I have a branch locally to migrate to bnd-maven-plugin):
https://github.com/orbinson/opentelemetry-osgi-wrappers/pull/2/files#diff-d6b3ba9da962b1033c832befd5b43ff90ea2528e07be4975707011b7b08401d9

My wish would be the contribute this to opentelemetry without having to wrap it myself, but then I'd like to make it as simple as possible for the people of opentelemetry so that they don't have to be OSGi gurus or even aware that something is happening ;)
open-telemetry/opentelemetry-java#6669
open-telemetry/opentelemetry-java#768

chrisrueger added a commit to chrisrueger/bnd that referenced this issue Oct 3, 2024
this is an experiment based on an idea mentioned in bndtools#6304

it leverages the recent addition of PR bndtools#5912 that allowed to add annotations in comments of files in META-INF/services. But in this PR we basically pretent and add a aQute.bnd.annotation.spi.ServiceProvider annotation artificially. this causes bnd to generate Provide-Capability manifest headers for the services

make sure biz.aQute.bndlib is on the buildpath which contains the 'aQute.bnd.annotation.spi.ServiceProvider' annotation

Signed-off-by: Christoph Rueger <chrisrueger@gmail.com>
@chrisrueger
Copy link
Contributor

chrisrueger commented Oct 3, 2024

@royteeuwen I found that almost everything needed is there already - added in https://github.com/bndtools/bnd/pull/5912/files#diff-6c05b50a9d4a861349bca27733122a0ea6c002f2d62086c9a857c310b2da2d41 by @pkriens

I created an experiment / prototype in #6309 which basically leverages this approach.
(still fails, needs discussion etc.)

@royteeuwen
Copy link
Author

Very nice! Thanks a lot for your effort

@chrisrueger
Copy link
Contributor

Closed via #6309

@royteeuwen
Copy link
Author

@chrisrueger Thanks a lot!

Any idea on when a new release would happen for the bnd plugin? I see the last release was already a year ago, so I'm not sure how often it happens?

@chrisrueger
Copy link
Contributor

@chrisrueger Thanks a lot!

Any idea on when a new release would happen for the bnd plugin? I see the last release was already a year ago, so I'm not sure how often it happens?

I don't know. In one of the last calls we discussed somewhere within the next weeks. I personally would like to get #6326 in. It is a nice addition to the new -metainf-services: auto which I surprinsingly needed in an own project :)

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

No branches or pull requests

3 participants