A assume we have agreed on [JBCL-167] which allows to resolve a Requirement in the Domain, I propose the following
We add the notion of a Resolver to MC
- Capability
- Requirement
- Module
- Wire
- Resolver
Its main purpose is to match the set of caps/reqs to produce a constent wiring. The algorithm should have osgi semantics and allow us to pass the core TCK
The Resolver would have an API similar to
// Adds a module to the resolver
void addModule(Module)
// Removes a module from the resolver
void removeModule(Module)
// Resolves the given set of Modules
boolean resolve(List<Module>)
// Get wire for a resolved requirement
Wire getWire(Requirement)
An implementation of
Module Requirement.resolves(Domain domain);
would call into the resolver to pickup the result.
The state of the resover can be decoupled from the actual runtime state to perform impact analysis. For example if we want to answer a question like: "Will the following saet of modules resolve cleanly on the runing system". This analysis would not affect the running sytem.
The actual implementation of the resolver would be impl detail and we could for our osgi effort start of with a delegation model to the felix resolver. The ultimate goal would be to have a standalone resolver that supports the union of required functionality for osgi and AS use cases.
In a broad sense, the osgi caps/reqs would be nativly supported by MC and can be resolved in a standard osgi way (i.e. we pass the TCK)
