ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Adams" <Jim.Ad...@sas.com>
Subject RE: Conflict manager problem
Date Wed, 31 Oct 2007 18:14:01 GMT
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:xavier.hanin@gmail.com]
> Sent: Wednesday, October 31, 2007 2:08 PM
> To: ivy-user@incubator.apache.org
> Subject: Re: Conflict manager problem
> 
> On 10/31/07, Jim Adams <Jim.Adams@sas.com> 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:xavier.hanin@gmail.com]
> > > Sent: Wednesday, October 31, 2007 2:56 AM
> > > To: ivy-user@incubator.apache.org
> > > Subject: Re: Conflict manager problem
> > >
> > > 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/
> >
> 
> 
> 
> --
> Xavier Hanin - Independent Java Consultant
> http://xhab.blogspot.com/
> http://ant.apache.org/ivy/
> http://www.xoocode.org/

Mime
View raw message