AbstractResourceResolver has a findResource() method. This method downloads an artifact even if it has been evicted.
> -----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/
