Community
Participate
Working Groups
In an effort to implement the RFC 112 resolver on top of the equinox resolver the following changes need to be made to the equinox resolver: API: - Currently only the BundleDescription interface has user objects. It would be very useful to allow all BaseDescription and all VersionConstraint implementations to have user objects. This would allow simple mappings between the equinox resolver objects (descriptions and specifications) onto the RFC 112 types (Capabilities and Requirements). - The StateObjectFactory needs more methods that allow for arbitrary construction of the Description and Specification objects based off of the standard osgi metadata. This would allow for simplification of creating BundleDescription objects from the org.osgi.framework.resource.Resource type. Provisional API: - Provisional API is needed to allow easy traversal from a Capability (returned by BaseDescription.getCapability()) back to the BaseDescription it represents. To do this a provisional org.eclipse.osgi.service.resolver.extras.DescriptionReference interface is introduced. - Provisional API is needed to allow easy traversal from a Requirement (returned by VersionConstraint.getRequirement()) back to the VersionConstraint it represnets. To do this a provisional org.eclipse.osgi.service.resolver.extras.SpecificationReference inteface is introduced. - An environment needs the ability to sort the list of candidates to indicate a sort order preference. To do this a new provisional interface org.eclipse.osgi.service.resolver.extras.Sortable<E> is introduced. This allows a resolver hook to sort the list of candidates. Behavior Changes: Aside from the implementation changes for the API above the following behavior changes are needed - Support the ability for a resolver hook to add more BundleDescription objects while its ResolverHook.filterCandidates method is called. The resolver implementation must detect that this has happened and try to gather the candidates again and resolve the constraint again. This allows the environment to dynamically add providers to the state when a requirement is resolved. - The candidate lists passed to the resolver hook should implement the provisional Sortable interface so that hooks can sort the candidates in the preference order they desire.
I have a branch with these changes that I plan to merge into master for M2.
Changes in commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=a4439d90f4dd7d1033f3dca6e92c3b7064b6f47f