How to override a Require-Capability generated by Bnd?

GENERAL
1

Hi,

I am trying to add some @ServiceProvider annotations to a project, but need to make the osgi.serviceloader.registrar requirement optional. My initial attempt involved setting

@ServiceProvider(value = MyProvider.class, resolution = Resolution.OPTIONAL)

but this has been rejected because Resolution.OPTIONAL is an enum, and the project owner does not want an unknown class reference injected into the byte-code.

My second thought was to configure maven-bundle-plugin such that:

<instructions>
    <Require-Capability>
        osgi.extender;filter:="(&amp;(osgi.extender=osgi.serviceloader.registrar)(version>=1.0.0)(!(version>=2.0.0)))";resolution:=optional
    </Require-Capability>
</instructions>

except that this just prepends an extra requirement into the manifest:

Require-Capability: osgi.extender;filter:="(&(osgi.extender=osgi.serviceloader.registrar)(version>=1.0.0)(!(version>=2.0.0)))";resolution:=optional,osgi.extender;filter:="(&(osgi.extender=osgi.serviceloader.registrar)(version>=1.0.0)(!(version>=2.0.0)))",osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"

I would obviously prefer to keep the osgi.ee requirement too, if possible. However, clobbering Bnd’s generated Require-Capability header entirely with one of my own would work too. Can anyone suggest how to “resolve” this problem please?

Thanks,
Chris

2

Why not remove the annotation?

And I think we have a @ServiceProvider annotation in bnd 7 that uses strings for this reason.

3

Why not remove the annotation?

I believe the @ServiceProvider annotation also instructs Bnd to generate a rather complicated-looking Provide-Capability attribute too.

My current solution is here, and it seems to be working OK. However, I would prefer not to hijack the maven-shade-plugin to put the Require-Capability header back.

And I think we have a @ServiceProvider annotation in bnd 7 that uses strings for this reason.

That sounds useful, although I wasn’t aware that Bnd 7 had been released yet.

I’ve also just tried compiling this project with Java 17 and received the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:compile (default-compile) on project woodstox-core: Compilation failure: Compilation failure: 
[ERROR] Source option 6 is no longer supported. Use 7 or later.
[ERROR] Target option 6 is no longer supported. Use 7 or later.
4

I believe the @ServiceProvider annotation also instructs Bnd to generate a rather complicated-looking Provide-Capability attribute too.

:slight_smile: Just copy and paste it and add the resolution is optional, as you already did. The annotations are less maintenance because class file name changes are picked up automatically. During processing, bnd will take the existing clauses and merge them with your clause. Because you also got the annotation, it now adds the mandatory requirement.

I think that is by far the easiest solution in a project where OSGi is treated as the not really so welcome guest.

5

I would actually consider this project to have been very welcoming of OSGi. They just didn’t know OSGi well enough to support it much.

That’s where I thought Bnd would come in.