after upgrading to 6.1.0 (skipped some versions, so the behavior may have been introduced earlier), I get warnings: "warning: osgi.serviceloader capability found with no 'register:' directive".
Could anybody please explain, why I get this warning? In the specs (checked both 7 and 8) I find (compendium, 133.5.1 Registering Services):
A Service Provider is selected by an osgi.serviceloader capability when:
The advertised Service Type matches the corresponding osgi.serviceloader capability’s Service Type, and
The register directive is absent, or
The register directive contains the fully qualified name of the Service Provider.
So it should be perfectly okay to have no register directive, shouldn’t it?
There’s also no “register” in the SPI Fly documentation (which is, of course, non normative).
First off, it’s merely a warning! (granted, it could be improved, suggestions welcome!) and if you don’t want bnd to manage your SPI descriptors then you could elide the warning message with -fixupmessages.
-fixupmessages.spi.plugin: osgi.serviceloader capability found with no 'register:' directive
[update 1]
Perhaps we should add a -no* instruction like we have done elsewhere.
Also, the message does finish with Descriptor cannot be managed for osgi.serviceloader;%s. However, maybe that isn’t quite capturing what Descriptor is in this case. maybe it it should add explicit META-INF/services/* or maybe even the complete service type since I believe it is aware of it at the moment the message is created.
[update 2]
here’s the improved message I’m testing:
osgi.serviceloader capability found with no 'register:' directive. Descriptor 'META-INF/services/test.annotationheaders.spi.SPIService' cannot be managed unless the osgi.serviceloader capability specifies the 'register:' directive; osgi.serviceloader="test.annotationheaders.spi.SPIService"
I would remove the first bit, but it’s likely that if anyone already has a -fixupmessages is probably on that first bit, so I’m thinking of keeping it for more backward compatibility.
Yes, it’s a warning, but I try to keep my projects warning-free (although this sometimes requires some suppress mechnism) else new warnings won’t be noticed. And before I suppress a warning, I want to understand what I’m doing. (Always assuming that there is a reason for the warning.)
The irritating issue here is that there is no reason for me to assume that bnd does anything regarding the service descriptors. I’m not using an annotation. I have a “plain” jar that provides a service which I want to be available in both a non-OSGi environment and in an OSGi environment (technically, it’s also a gradle non-workspace build, so bnd isn’t in the focus anyway, it’s just augmenting the jar). Therefore, of course, I write the META-INF/services/... descriptor myself and (in this environment) wouldn’t even consider having bnd do this.
I think whatever the message is, it should clearly indicate that this is a bnd problem that won’t prevent my bundle from working as expected. ("… cannot be managed …" without an explicit reference to bnd makes me assume that the OSGi framework won’t be able to manage it.) Best, of course, the warning should only appear when bnd’s features are really required, i.e. (from my preliminary understanding) when a META-INF/services/... descriptor isn’t already supplied and/or the SPI annotation is being used.
Our goal here is to support library developers (especially those who are doing OSGi as a mere convenience and not as primary focus, in fact we’d like BND be the tool you use for making good modular Java artifacts no matter what your target audience is… just also OSGi if we can do it innocuously).
If you have a capability for osgi.serviceloader, we can assume you want a descriptor, so we’re trying to save you some keystrokes. But see the PR where I’ve added a -no flag so you can turn this off…
But maybe we could also check if the file exists and make sure the content we’d expect is not there before doing anything.