MANIFEST generation for exported service component

GENERAL
1

For setting up a simple example I created a component that does not implement a service interface:

@Component(service=ConfigurableService.class)
public class ConfigurableService {
...
}

I also added the following package-info.java, as I want to be able to consume that component from a Gogo command:

@org.osgi.annotation.bundle.Export
@org.osgi.annotation.versioning.Version("1.0.0")
package org.fipro.ds.configurable;

The resulting MANIFEST looks strange to me. It also has an entry for the import of itself, and also has a uses constraint on itself:

Export-Package: org.fipro.ds.configurable;version="1.0.0"
Import-Package: java.io,java.lang,java.util,org.fipro.ds.configurable;
 version="[1.0,2)"
Provide-Capability: osgi.service;objectClass:List<String>="org.fipro.d
 s.configurable.ConfigurableService";uses:="org.fipro.ds.configurable"

It doesn’t seem to create issues anywhere. I just wonder if this is the intended result. It looks at least unexpected.

2

I also added the following package-info.java, as I want to be able to consume that component from a Gogo command:

Gogo command do not need visibility to the package. Gogo gets the service as Object so it will not need to import your package.

The resulting MANIFEST looks strange to me. It also has an entry for the import of itself,

This is actually one of the corner stones of OSGi. Packages are intended to be used for API. This means that different bundles can export the same package. This will allow the framework to pick one of the bundles as the central exporter and then the others should import the package. You can specify -noimport on the package if you want the package to never be imported. However, bnd analyzes your bundle to see if it makes sense and it rarely is wrong in this analysis. Best to stay away from these options.

and also has a uses constraint on itself:

The service you provide is in the given package so it is ‘used’ by the service.

Everything looks exactly as intended :slight_smile:

3

Maybe my description was not detailed enough. I want to create a Gogo command in another bundle that consumes the service. The service itself is not the Gogo command. Therefore I need the package visibility here.

But that’s just for clarification of the question. It doesn’t impact your answer. :slight_smile:

So, thanks for the explanation. If I got it right I have to see the package also as some sort of API, and as my exported service is in that package, it of course uses it. So I have to look at the package and the contained service as separated entities, and not as some sort of “contained entities”. And therefore ithe service “uses” the package in which it resides. Not sure if the wording is correct, but I think I got it now.

1 Like