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

[royteeuwen]

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]

This issue https://github.com/bndtools/bnd/pull/5912 and PR https://github.com/bndtools/bnd/issues/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]

@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]

@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]

👍 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]

-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]

@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]

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]

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 ;) https://github.com/open-telemetry/opentelemetry-java/pull/6669 https://github.com/open-telemetry/opentelemetry-java/issues/768

[chrisrueger]

@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 https://github.com/bndtools/bnd/pull/6309 which basically leverages this approach. (still fails, needs discussion etc.)

[royteeuwen]

Very nice! Thanks a lot for your effort

[chrisrueger]

Closed via https://github.com/bndtools/bnd/pull/6309

[royteeuwen]

@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]

@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 https://github.com/bndtools/bnd/pull/6326 in. It is a nice addition to the new -metainf-services: auto which I surprinsingly needed in an own project :)