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 18:36:31 GMT
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 <Jim.Adams@sas.com> 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: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/
>



-- 
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