On 10/31/07, Jim Adams <[EMAIL PROTECTED]> wrote: > > 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?
Yes, but this is out of the things that a ConflictManager is supposed to do ATM. So maybe you will have to think about a new API in ConflictManager to let it handle this case, and review the conflict management algorithm in ResolveEngine. 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? You should call the IvyNode#markEvicted(EvictionData) method. But I don't know if it's the responsibility of ConflictManager to call it or ResolveEngine. ATM it's the ResolveEngine, to keep the ConflictManager simple enough. But if we want to have more flexibility in what a ConflictManager can do, maybe we will have to shift the responsibilities. I don't have enough time to think about the best solution to this problem for the moment, so feel free to conduct your own study and share your thoughts and questions with us. Xavier > -----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/ > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
