What I am attempting to do is to get the resolver to basically start over. In the case I detail below there are 2 C versions out there and 2 D versions. I resolve to one of the D versions through B and then take the latest C version which gives a different D version. I evict the different D version. This needs to cause an eviction of the latest C version. If I reset back to looking for latest the findResource doesn't check for eviction before finding the latest version. Note that I have had to change some code just to get things to start over and I may not be resetting enough information, but that is what I am attempting.
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 31, 2007 2:08 PM > To: [email protected] > Subject: Re: Conflict manager problem > > On 10/31/07, Jim Adams <[EMAIL PROTECTED]> wrote: > > > > AbstractResourceResolver has a findResource() method. This method > > downloads an artifact even if it has been evicted. > > > You're right. Actually, it's the responsibility of the caller to avoid > downloading a module if it has been evicted. The logic of module eviction is > in the ResolveEngine and related classes, like IvyNode. See in particular > the IvyNode#loadData method, which calls getDependency on the resolver only > if the module has not been evicted. > > Do you have a case where an evicted module is still downloaded? Note that it > may happen that a module descriptor is downloaded because the module is > evicted after the module being resolved. To resolve conflicts, Ivy has to > find conflicts, and thus needs to download module metadata. But the > artifacts of a module shold never be downloaded if it has been completely > evicted. > > Xavier > > > -----Original Message----- > > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, October 31, 2007 2:56 AM > > > To: [email protected] > > > Subject: Re: Conflict manager problem > > > > > > On 10/29/07, Jim Adams <[EMAIL PROTECTED]> wrote: > > > > > > > > The issue that I chanced upon was that the code that actually > > downloads > > > > the ivy files from the repo can't get to the resolveData and there > > needs > > > > to be a way to not download already evicted modules. > > > > > > > > > Could you be more precise? Which piece of code are you referring to? > > > > > > Xavier > > > > > > > -----Original Message----- > > > > > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > > > > > Sent: Saturday, October 27, 2007 3:36 AM > > > > > To: [email protected] > > > > > Subject: Re: Conflict manager problem > > > > > > > > > > I think you can have access to the ResolveEngine, but it's not > > really > > > > the > > > > > most interesting, sicne all the state of resolution is in > > ResolveData, > > > > and > > > > > ResolveData is passed to the resolver. In the conflict manager you > > > > have > > > > > access to an IvyNode, which itself has access to ResolveData > > > > (#getData()), > > > > > which itself has access to resolve engine (#getEngine()). I think > > this > > > > > should be enough to have all the contextual information about the > > > > current > > > > > resolution process. > > > > > > > > > > Does it make sense? > > > > > > > > > > Xavier > > > > > > > > > > On 10/26/07, Jim Adams <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > In continuing to pursue this problem, it appears that the > > > > ResolveEngine > > > > > > does not provide any of its internal state to the Resolver > > itself. > > > > This > > > > > > means that there is no way to get back to the list of currently > > > > evicted > > > > > > modules and remove previously evicted modules from the list > > > > available in > > > > > > the findResource() method. Do you think that adding that bit of > > > > internal > > > > > > state is a good approach? > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jim Adams [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Friday, October 26, 2007 9:56 AM > > > > > > > To: [email protected] > > > > > > > Subject: Conflict manager problem > > > > > > > > > > > > > > I am attempting to write a conflict manager that needs to > > resolve > > > > > > > conflicting versions from across the tree. The case I am > > working > > > > on is > > > > > > > what we are calling the "Polygon of Death". > > > > > > > > > > > > > > A depends on B and C > > > > > > > B depends on D > > > > > > > C depends on D > > > > > > > > > > > > > > There are 2 versions of C and D where C1->D1 and C2->D2. There > > has > > > > > > been > > > > > > > only one published version of B such that B1->D1 > > > > > > > > > > > > > > A is using LATEST to find B and C > > > > > > > > > > > > > > The problem is that A finds C2 and never has a chance to back > > up > > > > to > > > > > > C1. > > > > > > > I can evict D2 by looking at the list of currently selected > > nodes > > > > and > > > > > > > finding an older version of D but I cannot then successfully > > evict > > > > C2. > > > > > > > It seems that the selection of the latest version of C does > > not > > > > take > > > > > > > into account that C2 was evicted. I am willing to make changes > > to > > > > IVY > > > > > > > and give them back in a JIRA but I would like a little > > guidence on > > > > > > where > > > > > > > to look. > > > > > > > > > > > > > > > > > > > > > Jim Adams > > > > > > > [EMAIL PROTECTED] > > > > > > > Principal Systems Developer > > > > > > > SAS Institute > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Xavier Hanin - Independent Java Consultant > > > > > http://xhab.blogspot.com/ > > > > > http://ant.apache.org/ivy/ > > > > > http://www.xoocode.org/ > > > > > > > > > > > > > > > > -- > > > Xavier Hanin - Independent Java Consultant > > > http://xhab.blogspot.com/ > > > http://ant.apache.org/ivy/ > > > http://www.xoocode.org/ > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/
