Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 357137 - Changes to equinox resolver to support RFC 112 resolver
Summary: Changes to equinox resolver to support RFC 112 resolver
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.8.0 Juno   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: Juno M2   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-08 14:38 EDT by Thomas Watson CLA
Modified: 2011-09-12 10:23 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Watson CLA 2011-09-08 14:38:02 EDT
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.
Comment 1 Thomas Watson CLA 2011-09-08 14:54:16 EDT
I have a branch with these changes that I plan to merge into master for M2.