[
https://issues.apache.org/jira/browse/ARIES-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13696982#comment-13696982
]
John Ross commented on ARIES-952:
---------------------------------
@Glyn
Right, I just wanted to get a sense of where "gembin" was at. I still think the
original requirement deserves attention but it's quite a bit more work, from
both a design and implementation perspective. I think the latter could be
addressed quickly by simply making the dependency on ApplicationModeller
optional. You would lose service dependency resolution at subsystem install
time, of course. But since that requires Blueprint anyway, it makes no
difference to someone without any blueprint.xml.
For the former, I see the following options.
(1) Have Subsystems use the application-modeller-standalone distribution (if
possible). This removes the Blueprint implementation dependency.
(2) Have Subsystems use the blueprint-parser standalone distribution (if
possible). This removes the Blueprint implementation dependency but would
require abandoning the modeller and going to the parser directly. This isn't
necessarily bad since Subsystems only needs the service dependency info from
the modeller. The rest (e.g., package, bundle, host, and generic
requirements/capabilities) it calculates itself. This eliminates the
possibility of eventually integrating fully with the modeller, however.
Both (1) and (2) allow for the possibility of using Blueprint implementations
other then Aries; however, I'm not sure if the Aries Blueprint Parser was
written for standard blueprint xml or requires certain Aries specific
constructs.
(3) Define a service that Subsystems would use to get the service capabilities
and requirements of not-yet-installed bundles. The core subsystems
implementation would have an optional dependency on these services. Any present
in the registry would be used to compute service capabilities and requirements
for subsystem resolution. This would make integration with other blueprint
providers straightforward, as well as additional service technologies such DS.
> Break dependency of Aries Subsystems on Aries Blueprint
> -------------------------------------------------------
>
> Key: ARIES-952
> URL: https://issues.apache.org/jira/browse/ARIES-952
> Project: Aries
> Issue Type: Improvement
> Components: Application, Subsystem
> Reporter: Glyn Normington
>
> Aries Subsystems currently has a hard dependency on Aries Blueprint (AB).
> When running Aries Subsystems in an environment where there is already a
> Blueprint implementation, we end up with duplicate Blueprint extenders, which
> is of course a recipe for disaster.
> One such environment is the Virgo kernel. Virgo depends on Gemini Blueprint
> (GB) because it uses the Spring DM function provided by GB. So it's not
> possible to substitute AB for GB.
> So the requirement is to make it possible to run Aries Subsystems with GB.
> Admittedly this may involve adding some GB code to support resource modelling
> for Blueprint, but that should be separated from the AB implementation.
> To reproduce the problematic environment, see
> https://github.com/glyn/aries-subsystems-on-virgo-kernel and follow the
> instructions in README.md. The web admin console can then be used to observe
> both GB and AB extenders running in the Virgo user region. Also, the nature
> of the hard dependency can be observed by deleting the Aries Blueprint core
> bundle from the Virgo kernel's repository/usr directory and restarting Virgo
> - the modeller no longer resolves:
> missing constraint in bundle
> <org.apache.aries.application.modeller_1.0.1.SNAPSHOT>
> constraint: <Import-Package:
> org.apache.aries.blueprint.services; version="[1.0.0,2.0.0)">
--
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
