But still, is there something to do in this situation? In my case this happens in automated tests and the tests fail. In this case trying to resolve some bundles on a second attempt is not feasible – I did it manually when investigating the issue.
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Kirchev, Lazar
Sent: Thursday, September 01, 2011 8:43 AM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Uses constraints conflict
Thanks a lot Tom. This sounds reasonable. I think it is exactly the case – the possible combinations are a large number indeed and when debugging I saw there really was some merging and reduction. On the second attempt there is only one bundle for resolving and the set of possible solutions certainly is smaller. I wanted just to make sure that this is the expected behavior of the resolving algorithm.
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Watson
Sent: Wednesday, August 31, 2011 9:24 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Uses constraints conflict
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
"Kirchev, Lazar" ---08/31/2011 11:11:16 AM---Hello,
From:
| 
"Kirchev, Lazar" <l.kirchev@xxxxxxx>
|
To:
|
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
