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 Thu, 01 Nov 2007 07:33:51 GMT
On 10/31/07, Jim Adams <Jim.Adams@sas.com> 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:xavier.hanin@gmail.com]
> > Sent: Wednesday, October 31, 2007 2:37 PM
> > To: ivy-user@incubator.apache.org
> > 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 <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/
>



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