Plugable OSGi Resolver
JBOSGI-209 - Resolver preferences
Adrian says:
These are really aimed at resolving rules for ambiguous cases. I don't have a problem with tightening up these rules in jboss-cl
but two of them appear to be about split packages rather than ambiguities.
* A resolved exporter must be preferred over an unresolved exporter.
There is no notion of this in jboss-cl. There will be some preference for previously resolved dependencies
since it resolves first against the ClassLoaderSpace and only then looks at what is in the Domain.
But this is not the exact same semantic since the ClassLoaderSpace can contain unresolved stuff.
However, to me this is a split package and it should resolve to all them with the same version, unless some
rule (e.g. your split package policy) says otherwise.
* An exporter with a higher version is preferred over an exporter with a lower version.
This should already work. If it does not then show an example on a bug report.
* An exporter with a lower bundle ID is preferred over a bundle with a higher ID.
There is no direct notion of this in jboss-cl, but it should behave in a similar way since the Modules are stored in registration order in a List
inside the Domain. But again this is split package stuff.
NOTE: It is not a split package if they have the same package name but a different version. These are different packages.
The general direction to the resolver problem is currently to cooperatively work with Equinox, Felix on their standalone OSGi Resolver project. As you sure know, the OSGi resolver algorithm is not trival especially when it comes to "uses" and dependencies that can optionally be resolved to achieve a concistent resolution result. There is also a call for resolver "try runs" to predict/evaluate the future state of a system before bundles get actually installed in the framework. Calculating the implicit trasitive closure of subsystems also requires access to the notion of standalone OSGi resolution that happens outside of the actual framework.
Generally, because the resolve algorithm that is currently available in the MC is not yet suitable for the rich OSGi semantics we (i.e. Ales and I ) agreed to work on a pluggable module resolver. A correct resolver can reason about all possible wirings and may need to retry different wirings to find the best resolution. This becomes especially important when we add support for the uses clause on export packages.
The related issues are
https://jira.jboss.org/jira/browse/JBKERNEL-54
https://jira.jboss.org/jira/browse/JBKERNEL-55