aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Ross (JIRA)" <>
Subject [jira] [Commented] (ARIES-1108) Discuss a better user experience when dealing with service dependencies.
Date Thu, 29 Aug 2013 11:22:52 GMT


John Ross commented on ARIES-1108:

> Updating the maven-bundle-plugin probably won't help much. The Export-Service header
is generated for blueprint bundles (and those do already work).

Interesting because I think I like this idea the best out of the five. I don't understand
how Export-Service is working (but would like to) because it doesn't work for me. Presumably,
something in your environment is parsing Export-Service and making the service capability
available to the system. Which framework implementation are you using? What does your bundle
stack look like? Generating the appropriate Provide-Capability headers should be a "universal"
solution (on R5+ frameworks).

> What does uninstalling the application modeller mean, are only service requirements not
computed or also wiring stuff (pakage imports etc.)?

It affects only service requirements. All others are still computed.

> One additional thing for short term. The limitations described here (and on the mailing
list) should probably be somewhere in the documentation. At least for me it was not clear
from the aries subsystem documentation and the OSGi enterprise spec that subsystems try to
resolve service dependencies at all.

I have updated ARIES-1057 with this request.
> Discuss a better user experience when dealing with service dependencies.
> ------------------------------------------------------------------------
>                 Key: ARIES-1108
>                 URL:
>             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

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:

View raw message