[
https://issues.apache.org/jira/browse/ARIES-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Ross updated ARIES-1108:
-----------------------------
Description:
Currently, Aries Subsystems will compute service requirements and capabilities
for Blueprint bundles only. This can be particularly problematic for users with
application subsystems having bundles with service dependencies on
non-blueprint bundles outside of their control. For example, an application
blueprint bundle with a service dependency on EventAdmin will fail to resolve
unless the EventAdmin implementation bundle advertises the service capability
in some supported way. To get around this, the user must either (1) turn the
bundle into a blueprint bundle, (2) add a Provide-Capability header to the
bundle's manifest, or (3) provide their own bundle with a Provide-Capability
header advertising all of the services of interest.
The following represents a non-exhaustive list of possibilities.
(1) Engage bundle providers to include a Provide-Capability header advertising
services. This would be particularly helpful for standard OSGi services. Engage
OSGi to make this a requirement or best practice.
(2) Update the maven bundle plugin to generate this header, as it currently
does for the Export-Service header.
(3) Support Import-Service and Export-Service headers in Aries Subsystems.
These headers are already generated by the maven bundle plugin.
(4) Support DS in Aries Subsystems.
(5) Add some sort of service listener to Aries Subsystems that will ensure
existing services are available as "virtual capabilities" to resolving
subsystems.
Note that in Aries Subsystems 1.0.1-SNAPSHOT+, the ModelledResourceManager
service, used to compute service requirements and capabilities, is now
optional. This means users can uninstall (or not install) the
org.apache.aries.application.modeller bundle in order to disable service
resolution.
was:
Currently, Aries Subsystems will compute service requirements and capabilities
for Blueprint bundles only. This can be particularly problematic for users with
application subsystems having bundles with service dependencies on
non-blueprint bundles outside of their control. For example, an application
blueprint bundle with a service dependency on EventAdmin will fail to resolve
unless the EventAdmin implementation bundle advertises the service capability
in some supported way. To get around this, the user must either (1) turn the
bundle into a blueprint bundle, (2) add a Provide-Capability header to the
bundle's manifest, or (3) provide their own bundle with a Provide-Capability
header advertising all of the services of interest.
The following represents a non-exhaustive list of possibilities.
(1) Engage bundle providers to include a Provide-Capability header advertising
services. This would be particularly helpful for standard OSGi services. Engage
OSGi to make this a requirement or best practice.
(2) Update the maven bundle plugin to generate this header, as it currently
does for the Export-Service header.
(3) Support Import-Service and Export-Service headers in Aries Subsystems.
These headers are already generated by the maven bundle plugin.
(4) Support DS in Aries Subsystems.
(5) Add some sort of service listener to Aries Subsystems that will ensure
existing services are available as "virtual capabilities" to resolving
subsystems.
> Discuss a better user experience when dealing with service dependencies.
> ------------------------------------------------------------------------
>
> Key: ARIES-1108
> URL: https://issues.apache.org/jira/browse/ARIES-1108
> Project: Aries
> Issue Type: Brainstorming
> Components: Subsystem
> Reporter: John Ross
>
> Currently, Aries Subsystems will compute service requirements and
> capabilities for Blueprint bundles only. This can be particularly problematic
> for users with application subsystems having bundles with service
> dependencies on non-blueprint bundles outside of their control. For example,
> an application blueprint bundle with a service dependency on EventAdmin will
> fail to resolve unless the EventAdmin implementation bundle advertises the
> service capability in some supported way. To get around this, the user must
> either (1) turn the bundle into a blueprint bundle, (2) add a
> Provide-Capability header to the bundle's manifest, or (3) provide their own
> bundle with a Provide-Capability header advertising all of the services of
> interest.
> The following represents a non-exhaustive list of possibilities.
> (1) Engage bundle providers to include a Provide-Capability header
> advertising services. This would be particularly helpful for standard OSGi
> services. Engage OSGi to make this a requirement or best practice.
> (2) Update the maven bundle plugin to generate this header, as it currently
> does for the Export-Service header.
> (3) Support Import-Service and Export-Service headers in Aries Subsystems.
> These headers are already generated by the maven bundle plugin.
> (4) Support DS in Aries Subsystems.
> (5) Add some sort of service listener to Aries Subsystems that will ensure
> existing services are available as "virtual capabilities" to resolving
> subsystems.
> Note that in Aries Subsystems 1.0.1-SNAPSHOT+, the ModelledResourceManager
> service, used to compute service requirements and capabilities, is now
> optional. This means users can uninstall (or not install) the
> org.apache.aries.application.modeller bundle in order to disable service
> resolution.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
