Thanks. Here is what I am trying to do and maybe you can help I am trying to force the parent node to become evicted if a child node resolves to nothing. Make sense? This is the case where I needed to evict the child when it was the only one available. There is a lot of code that evicts the children but nothing that evicts the parent. Which data structures must be updated to insure an eviction?
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 31, 2007 2:37 PM > To: [email protected] > Subject: Re: Conflict manager problem > > OK I think I get it. You would like to have a version resolution taking into > account evicted modules, and that's where the findResource method is missing > information (a reference to ResolveData would be fine). The problem is that > there is already a lot of information conveyed to this method (you see the > number of arguments... ugly :-( ). I was already thinking that we could > review this kind of methods to distinguish between the real arguments and > contextual information. Contextual information could go into IvyContext IMO, > and ResolveData could be considered part of the contextual information. This > obviously requires modification in Ivy itself, but we are not opposed to > good patches :-) > > Xavier > On 10/31/07, Jim Adams <[EMAIL PROTECTED]> wrote: > > > > 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/ > > > > > > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/
