Use namespace, directives and attributes to compare equal of Requirement #538
Conversation
Currently the resolver is ultra slow in some scenarios and even never finds a valid solution, just adding more and more permutations to check. The reason is that one check that should actually *reduce* the number of problematic permutations fails because it uses Requirement#equals what is incapable of compare requirements across Resource boundaries, that means even if the requirement describes the same restrictions it is not considered equal and therefore selected as a possible permutation to remove this, then the validation check detects this is unresolvable adding possible new permutations and so on. This now performs an equals check instead on namespace, directives and attributes (what can be disabled by a system property) what makes the resolver in such case from running forever to just an blink of an eye.
|
In my example there is the following requirements from two bundles that are using substitution packages: their toString looks equals but if you look into the object you will see that one requirement is from
and the other from
so using equals compare them as false resulting in (the drop of lines is where the resolver gives up after one minute):
after apply they fix this results in the following:
|
|
@timothyjward fyi |
| @@ -1260,6 +1287,25 @@ public boolean canRemoveCandidate(Requirement req) | |||
| return false; | |||
| } | |||
|
|
|||
| private boolean isMatchingRequirement(Requirement requirement, Requirement other) { | |||
| if (USE_REQUIREMENTS_EQUALS) { | |||
There was a problem hiding this comment.
you may want to document this fallback somewhere or name it *_FALLBACK
But they are two different requirements because they are from two different bundles. |
|
Convert to draft as it does not seem to solve the issue in all cases... |
|
@tjwatson I agree that this seems not the correct way to address the issue, I'll closing this for now and try to came up with an improved solution. This has most probably be detected in the inital collection of candidates so the resolver can't run into a conflict. |
|
I have now pushed some experiments to the PR that contains the testcase(s) that show the explosion of permutations here: |
Currently the resolver is ultra slow in some scenarios and even never finds a valid solution, just adding more and more permutations to check.
The reason is that one check that should actually reduce the number of problematic permutations fails because it uses Requirement#equals what is incapable of compare requirements across Resource boundaries, that means even if the requirement describes the same restrictions it is not considered equal and therefore selected as a possible permutation to remove this, then the validation check detects this is unresolvable adding possible new permutations and so on.
This now performs an equals check instead on namespace, directives and attributes (what can be disabled by a system property) what makes the resolver in such case from running forever to just an blink of an eye.
@tjwatson this dramatically reduces resolving time and leads to a resolved state where previously confusing use constraint violation and missing packages are reported that are actually resolvable. For my example described here:
it goes from minutes (until it hits the timeout) to milliseconds, I therefore suggest to include this in RC1, I added a system property as last resort if this would break something badly, so please review and give +1 as PL, for the record I would also give +1 as PL but would want your vote and review as binding here!
FYI @tivervac