It sounds like the issue is running into a case where the algorithm reduces the number of possible combinations to try so that it could reduce the overall resolution time. When the resolver algorithm is faced with a large number of possible solutions it tries to take some short cuts by throwing out many of the possible solutions. One of these "reductions" is to take group the requirements which has the exact same list of possible candidates and treat them as a single permutation. This obviously leaves some possibly valid solutions out, but not doing can result in very long (endless?) resolution times.
So what could be happening is that on the first resolution we are resolving
as many bundles as possible but we have a rather large set of possible
solutions to pick from which results in a reduction of possible solutions
to try. This forces some of your bundle to not resolve even though there
may have been a valid solution that we ended reducing out of the candidate
solutions. On your second attempt to result we have a much smaller set of
bundles to resolve which equates to a much smaller set of possible
solutions. Now we don't have to do any reductions and can fully permeate
the possible solutions and find the one that provides a valid class space.
Tom
From: "Kirchev, Lazar" <l.kirc...@sap.com>
To: Equinox development mailing list <equinox-dev@eclipse.org>
Date: 08/31/2011 11:11 AM
Subject: [equinox-dev] Uses constraints conflict
Hello,
I have a resolution problem due to a uses constraints conflict. My setup
includes a large number of bundles and a lot of the exports contain uses
directives. Upon initial startup one of the bundles fails to resolve due to
a uses constraint conflict. However, if I refresh this bundle after that,
it gets resolved. Is this behavior expected?
I debugged the uses constraints checking code, and I observed that packages
from three bundles are identified to have uses constraints conflicts. From
the involved imported packages two have more than one possible supplier
(both have two suppliers). When iterating the four possible combinations of
the suppliers of the imports, the best case turns out to have two resolved
and one unresolved bundle and the algorithm chooses this combination.
But still, when the algorithm checks a particular combination, it checks if
it can wire the packages of all three bundles to the chosen suppliers. Is
this OK? Isn’t it possible that one of the bundles have a different
supplier than the other two? Because this is what actually happens when the
unresolved bundle is refreshed – it is wired to a different supplier then
the other two and then it is successfully resolved.
Regards,
Lazar_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
