Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 358923

Summary:	[R5] Improve support for multiple cardinality and uses constraints on generic capabilities
Product:	[Eclipse Project] Equinox	Reporter:	Thomas Watson <tjwatson>
Component:	Framework	Assignee:	Thomas Watson <tjwatson>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	tdiekman
Version:	3.8.0 Juno
Target Milestone:	Kepler M3
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Thomas Watson

2011-09-26 12:03:36 EDT

In bug 350960 we added support for multiple cardinality on the Require-Capability header.  This works OK as long as the capabilities do not have uses constraints.  As soon as matching capability is encountered which has a uses constraint on it then the Require-Capability is treated as a single cardinality.  This needs to be improved, but is not going to be simple.

For cardinality multiple, if there are multiple capabilities with multiple uses constraints then it will be next to impossible (at least to my mind) to determine a reasonable heuristic for traversing the solution set in order to find a valid and consistent class space for the capability requirement.  

I think one reasonable approach would be to post process the multiple cardinality requirements that have 2 or more matching capabilities.  This would be done after selecting the solution for all the other single cardinality requirements.  Then for multiple cardinality requirements with 2 or more matching capabilities we would prune from the list of matching capabilities the ones that don't provide a consistent class space for the solution selected.

Comment 1 Thomas Watson

2012-04-25 11:41:20 EDT

Not for Juno.

Comment 2 Thomas Watson

2012-06-25 08:25:47 EDT

*** Bug 383361 has been marked as a duplicate of this bug. ***

Comment 3 Thomas Watson

2012-10-10 11:35:21 EDT

I released a fix and a test with commit:

http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=c4443d18acafe486c4f38ea4ce880a304ba8892f

Here is the approach taken:

1) for cardinality:=multiple requirements I do not consider the requirement when permuting over the set of possible solutions checking for a valid class space.
2) the algorithm makes a selection for the providers of all the requirements with 'single' cardinality
3) for 'multiple' cardinality requirements the algorithm checks to see if one or more providers allow for a valid class space and discards all the providers that do not.  If the requirement is mandatory then resolution only succeeds if there is at least one provider that can contribute to a valid class space.

This approach seems to avoid the explosion of permutations I was fearing would be introduced if we had to permute over all the combination of possible supplier sets for a 'multiple' cardinality requirement.