ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Conflict manager problem
Date Wed, 31 Oct 2007 06:55:57 GMT
On 10/29/07, Jim Adams <Jim.Adams@sas.com> 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:xavier.hanin@gmail.com]
> > Sent: Saturday, October 27, 2007 3:36 AM
> > To: ivy-user@incubator.apache.org
> > 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 <Jim.Adams@sas.com> 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:Jim.Adams@sas.com]
> > > > Sent: Friday, October 26, 2007 9:56 AM
> > > > To: ivy-user@incubator.apache.org
> > > > 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
> > > > Jim.Adams@sas.com
> > > > 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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message