Community
Participate
Working Groups
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.
Not for Juno.
*** Bug 383361 has been marked as a duplicate of this bug. ***
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.
