[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] Succesive resolutions again...
|
Hi Filip,
You're right as usual. I think I've made the necessary changes to accommodate this case now.
It's been committed to our CVS. You will see a lot of other changes as well since I was in
the middle of an API change to accommodate a BOM component type when I started to look at this.
Regards,
Thomas Hallgren
Filip Hrbek wrote:
Hi,
I found one more problem in succesive resolution calls.
Let's say that we have 2 resolvers/rmaps for resolution of our well
known component buckminster.test.simple_d.
RMAP1 is able to resolve the component buckminster.test.simple_c
RMAP2 is able to resolve components buckminster.test.simple_a,
buckminster.test.simple_b and buckminster.test.simple_d
The first resolution on RMAP1 doesn't resolve anything (there is no
search path for simple_d)
The second resolution on RMAP2 resolves simple_d, its dependencies, then
simple_a and simple_b, but simple_c remains unresolved since there is no
search path for simple_c
The third resolution on RMAP1 again should resolve the last remaining
component, i.e. simple_c - it has the desired search path this time
Using the latest BM, the third resolution does nothing and the BOM
remains unresolved.
Quick fix: Comment out lines #272 and #273 in ResolverNode.java. This
condition returns false when checking the top node simple_d, but it
should not - the component simple_d misses resolution of the component
simple_c.
*synchronized*(*this*)
{
//if(isResolved())
// return false;
*boolean* didSchedule = *false*;
I suppose that the top node should not be marked as resolved if any of
its component remains unresolved. The above mentioned quick fix just
illustrates the situation.
Regards
Filip Hrbek