You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jon Schneider <jk...@gmail.com> on 2009/10/12 17:47:01 UTC

Incremental Resolve

I created a JIRA wish (IVY-1134) for this where I maybe should have posted
it here first:

I am trying to integrate an Eclipse Zest (GEF) Ivy resolve visualizer into
IvyDE (see IVYDE-208) to help our developers visualize the eviction process
and to see how transitive dependencies were brought into the classpath. What
started out as a visualizer is now being considered as a type of editor as
well. Of course, if we edit a node visually (whether it be changing a
version, excluding a node, toggling the transitive attribute, etc.), we have
to perform a resolve against the whole ivy file associated with that
visualization (which may not be quick). I want to get some opinions on an
incremental resolve feature, which would somehow compare the cached resolve
file with the changing ivy file and resolve just the delta.

So just brainstorming, here are my thoughts:
We could persist a copy in the user's local cache of relevant pieces
(dependencies, maybe configurations) of the ivy file whenever a resolve is
performed so that the file can be compared on a subsequent resolve.  We can
pretty easily resolve just the particular dependencies that change using the
existing infrastructure, and I think the results could only have two impacts
on the rest of the tree stemming from evictions and
exclusions.

Thoughts?

Re: Incremental Resolve

Posted by Xavier Hanin <xa...@gmail.com>.
Hello Jon,
I really like the idea you have with your resolve visualizer! And indeed an
incremental resolve would make a lot of sense. The only problem is that it's
not very easy to implement, because it has to touch the very internal
behavior of Ivy which is sadly not very well documented (I blame myself for
that).

That being said, storing the resolution after a resolve is not difficult:
currently Ivy already stores quite a lot of information in the xml
resolution report, which might be enough. Another approach would be to make
IvyNode and related classes serializable and just dump the whole graph on
disk using serialization. Then to perform the incremental dependency
resolution you will have to look at how the ResolveEngine work, and how you
could invoke it on an existing graph in which you change only a couple of
dependencies... Not sure of how much changes are required, it partly depends
on the kind of changes you want to allow in the incremental resolve.

If you need some help to bring some light on the code with an historical
point of view I'll try to help. Don't be afraid with the delay though, I'm
overbooked by my job and a recently born kid.

Xavier

On Mon, Oct 12, 2009 at 17:47, Jon Schneider <jk...@gmail.com> wrote:

> I created a JIRA wish (IVY-1134) for this where I maybe should have posted
> it here first:
>
> I am trying to integrate an Eclipse Zest (GEF) Ivy resolve visualizer into
> IvyDE (see IVYDE-208) to help our developers visualize the eviction process
> and to see how transitive dependencies were brought into the classpath.
> What
> started out as a visualizer is now being considered as a type of editor as
> well. Of course, if we edit a node visually (whether it be changing a
> version, excluding a node, toggling the transitive attribute, etc.), we
> have
> to perform a resolve against the whole ivy file associated with that
> visualization (which may not be quick). I want to get some opinions on an
> incremental resolve feature, which would somehow compare the cached resolve
> file with the changing ivy file and resolve just the delta.
>
> So just brainstorming, here are my thoughts:
> We could persist a copy in the user's local cache of relevant pieces
> (dependencies, maybe configurations) of the ivy file whenever a resolve is
> performed so that the file can be compared on a subsequent resolve.  We can
> pretty easily resolve just the particular dependencies that change using
> the
> existing infrastructure, and I think the results could only have two
> impacts
> on the rest of the tree stemming from evictions and
> exclusions.
>
> Thoughts?
>



-- 
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator & leader - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/