[
https://issues.apache.org/jira/browse/ARIES-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753372#comment-13753372
]
Stephan Siano commented on ARIES-1108:
--------------------------------------
I like the idea (5) because the subsystem implementation kind of provides the
root subsystem and the services exported by these bundles are somewhat provided
by the root subsystem.
Option 4 might also help in several cases, however not all services are
provided by DS or blueprint (although this is good practice).
Option 1 is a long term solution, however I don't know how long it takes till
everybody has taken this up (even if it becomes a best practice).
Updating the maven-bundle-plugin probably won't help much. The Export-Service
header is generated for blueprint bundles (and those do already work).
The import and export service headers are somehow informational only, and I
don't think that changing the semantics of that is a good idea.
What does uninstalling the application modeller mean, are only service
requirements not computed or also wiring stuff (pakage imports etc.)?
> 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
