After update to 6.5.0, in osgi/felix runtime the bundle is not started due to missing dependency

[oana-dc]

In the version 6.5.0, the osgi.serviceloader.registrar is no longer optional.
The Require-Capability: 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))"

In absence of an osgi service loader, the bundle is not started. The runtime error :

org.osgi.framework.BundleException: Unable to resolve com.fasterxml.woodstox.woodstox-core [16](R 16.0):
missing requirement [com.fasterxml.woodstox.woodstox-core [16](R 16.0)] osgi.extender; (&(osgi.extender=osgi.serviceloader.registrar)(version>=1.0.0)(!(version>=2.0.0)))
Unresolved requirements: [[com.fasterxml.woodstox.woodstox-core [16](R 16.0)] osgi.extender; (&(osgi.extender=osgi.serviceloader.registrar)(version>=1.0.0)(!(version>=2.0.0)))]
[ERROR] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
[ERROR] at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
[ERROR] at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1566)
[ERROR] at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
[ERROR] at java.base/java.lang.Thread.run(Thread.java:829)

Searching the issues, I found an older one, with the same subject:
#154
The resolution was to make it optional.

[cowtowncoder]

@chrisr3 I have a sense of Deja Vu here... did I manage to break something wrt 6.5.0 release? :-/

[chrisr3]

@chrisr3 I have a sense of Deja Vu here... did I manage to break something wrt 6.5.0 release? :-/

Well, you seem to have reverted this, if that's what you mean:

commit c8e64cb146b3902aec0a88c9fd2b387c18bf8f58
Author: Tatu Saloranta <[email protected]>
Date:   Wed Jan 11 19:38:01 2023 -0800

    Revert "Declare osgi.serviceloader.registrar requirement as optional. (#155)" (#164)
    
    This reverts commit bc4ce73b56514928742c643e02e22bffedc63607.

I think the problem was that the OPTIONAL setting for this annotation is an Enum and not a String, and some byte-code scanner was warning that it couldn't find the Enum class. So until Bnd modifies their annotation, we're going to need to create this particular piece of OSGi metadata manually 🤦.

---

Something like #172, perhaps?

[cowtowncoder]

@chrisr3 Ah. Ok, yes, that was the issue: annotation-based mechanism to ease life of OSGi users broke tooling of some non-OSGi users (or required adding dependencies).

I'd be happy to merge #172, publish 6.5.1, as long as someone could try confirming it helps (I trust it should but cannot independently really verify myself).

@oana-dc Do you think you could try building snapshot from PR #172 and see if that would work better? That'd be super helpful if possible.

[cowtowncoder]

Fixed for 6.5.1 (now published) via #172. I hope.