Declare osgi.serviceloader.registrar requirement as optional

[chrisr3]

The osgi.serviceloader.registrar requirement is satisfied by Apache Aries SPI-Fly, and java.util.ServiceLoader cannot work inside an OSGi framework without it.

However, it is probably better to allow people to discover a need for SPI-Fly themselves rather that throwing bundle resolution errors at them when they upgrade woodstox-core 😊.

[cowtowncoder]

Sounds good, will merge for 6.3.1.

[cowtowncoder]

Merged; I will try to get 6.3.1 release out in near future, given that this can avoid awkward upgrade experiences that users like @selundqma have had :)

[cowtowncoder]

Sigh. Looks like this just causes issues through-out non-OSGi Java realm.

And I will probably need to revert this from 6.5.0.
Not sure how to help OSGi use cases.

[chrisr3]

I've had a chat with the Bnd developers, and they reckon they can modify their annotations to use String rather than enums.

[cowtowncoder]

@chrisr3 That would be great.

[kriegfrj]

The osgi.serviceloader.registrar requirement is satisfied by Apache Aries SPI-Fly, and java.util.ServiceLoader cannot work inside an OSGi framework without it.

Actually, this isn't ''strictly'' true in more recent versions of SPI-Fly. Because the lack of the necessary osgi.serviceloader.registrar property was a common problem, @rotty3000 added a configurable override so that you can manually configure SPI-Fly to treat certain bundles as if they had the necessary provider/consumer metadata. See Dynamic weaving by auto properties.

However, it is still better to have the bundle declare its own requirements, rather than throw that responsibility back onto the pour soul trying to assemble the application...

However, it is probably better to allow people to discover a need for SPI-Fly themselves rather that throwing bundle resolution errors at them when they upgrade woodstox-core 😊.

Agree. 😄