Community
Participate
Working Groups
We should consider adding Provide-Capability manifest headers to bundles that provide services. For example, Provide-Capability: osgi.service;objectClass=org.osgi.service.event.EventAdmin. This would allow those capabilities to be used "out of the box" by applications such as OSGi Subsystems when resolving dependencies. We should also consider doing this within the framework for services such as PackageAdmin, etc.
If we do this then the uses directive should be added for the service package. I also would think this would be an 'active' time effectiveness: Provide-Capability: osgi.service; objectClass="org.osgi.service.event.EventAdmin"; uses:="org.osgi.service.event"; effective:="active"
(In reply to comment #1) > If we do this then the uses directive should be added for the service > package. I also would think this would be an 'active' time effectiveness: +1 > > Provide-Capability: > osgi.service; > objectClass="org.osgi.service.event.EventAdmin"; > uses:="org.osgi.service.event"; > effective:="active" Per the spec (135.4), the type of the objectClass attribute in the osgi.service namespace is List<String> So the corrected capability for the EventAdmin service example would be: Provide-Capability: osgi.service; objectClass:List="org.osgi.service.event.EventAdmin"; uses:="org.osgi.service.event"; effective:="active" (We can use List instead of List<String> since String is the default scalar type for Lists.)
*** Bug 427191 has been marked as a duplicate of this bug. ***
I'm looking for this to improve the Eclipse product configuration. Currently a user needs to specify the start levels for org.eclipse.equinox.ds and org.eclipse.equinox.event to make the declarative services and event handling work correctly. From my understanding the configuration of the start levels should not be necessary if the capability headers are specified correctly. Is that correct? Regarding that, I disagree to specify effective:="active", because that would not lead to resolve the bundles correctly. I think effective:="active" is not correct because I have found the following explanation [1] "The OSGi framework resolver only considers Capabilities without an effective directive or effective:=resolve. Capabilities with other values for the effective directive can be considered by an external agent." Therefore I think this should be the correct capability. I would keep the List<String>. Although the default scalar type for Lists, it is clear for someone who checks the sources and is not aware of the default. Provide-Capability: osgi.service; objectClass:List<String>="org.osgi.service.event.EventAdmin"; uses:="org.osgi.service.event" [1] http://bnd.bndtools.org/heads/provide_capabaility.html
(In reply to Dirk Fauth from comment #4) > I'm looking for this to improve the Eclipse product configuration. Currently > a user needs to specify the start levels for org.eclipse.equinox.ds and > org.eclipse.equinox.event to make the declarative services and event > handling work correctly. > > From my understanding the configuration of the start levels should not be > necessary if the capability headers are specified correctly. Is that correct? No there are two things being configured for DS and event admin currently 1) the DS and event admin implementations providing the capabilities must still be persistently activated in order for it to provide the actual service at runtime. 2) The start-levels are not strictly required as long as bundles consuming the capabilities can do so dynamically. Right now the start-levels are set such that the DS impl and event admin impl are available at runtime before lazily activating the rest of the bundles. This simplifies life of the consuming bundles, but does lead to bugs being covered up for dynamically handling when these bundles change at runtime. In my opinion p2 should persistently mark all installed bundles for activation according to their activation policy. Unfortunately p2 does not do this. It only persistently activates bundles that have been explicitly configured to be activated. I think the default should be activate with activation policy and only additional configuration should be needed to NOT activate an installed bundle. See bug 177641 for some details. I believe it to be a rare condition to want to install a bundle but not activate it. > > Regarding that, I disagree to specify effective:="active", because that > would not lead to resolve the bundles correctly. I agree the capability directive should be effective:="resolve" (or nothing to take the default of "resolve". On the requirement side the directive should be effective:="active" though. > > I think effective:="active" is not correct because I have found the > following explanation [1] > > "The OSGi framework resolver only considers Capabilities without an > effective directive or effective:=resolve. Capabilities with other values > for the effective directive can be considered by an external agent." > > Therefore I think this should be the correct capability. I would keep the > List<String>. Although the default scalar type for Lists, it is clear for > someone who checks the sources and is not aware of the default. > > Provide-Capability: > osgi.service; > objectClass:List<String>="org.osgi.service.event.EventAdmin"; > uses:="org.osgi.service.event" > > [1] http://bnd.bndtools.org/heads/provide_capabaility.html
New Gerrit change created: https://git.eclipse.org/r/75779
I just pushed a first patch to Gerrit for EventAdmin as specified in this ticket. If that is fine I can go on with the other services if you can give me a hint where to look at. Not sure if I catch all. I additionally added a p2.inf file to provide the customized metadata for the p2 resolver.
Gerrit change https://git.eclipse.org/r/75779 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=63a12212a6b253c03ab5e1945baecac4daeb4dc6
New Gerrit change created: https://git.eclipse.org/r/76165
I did a check on the bundles that contain services I am aware of. Only cm was missing the Provide-Capability header. I added that with the latest patch together with some p2.inf files to be able to specify a requirement on a capability the p2 way also.
Gerrit change https://git.eclipse.org/r/76165 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=62a50bbac77fb5b15d47bb6acec67e27716dff0e
Marking as fixed.
