Re: [buckminster-dev] Succesive resolutions again...

[Thomas Hallgren <thomas@xxxxxxx>]

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
>