[jira] Commented: (IVY-1134) Incremental Resolve

["Jon Schneider (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IVY-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776443#action_12776443 ] 

Jon Schneider commented on IVY-1134:
------------------------------------

As I think more about this, I find that the pitfalls would outweigh the benefits.  Specifically, suppose the dependency tree looks something like :

A -> B -> C
A -> D -> C

Furthermore, assume B's dependency on C involves a wildcard, and D statically depends on version 1.0 of C and that at a particular time, the wildcard dependency of B -> C resolves the 1.0 version of C.

Now suppose version 1.1 of C is installed in the repository and we change the version of D (but the changed version of D still depends on C 1.0).  The incremental resolve ignores the B -> C subtree because B has not changed, and instead resolves D.  In the end, the resolve leaves us with C 1.0 where a full resolve would leave us with C 1.1.

For the purposes of the Resolve Visualizer, if we can parse the caller tree of the ResolveReport such that we reconstruct the IvyNode instances as they were when the ResolveReport was generated, this incremental resolver is not really needed.

> Incremental Resolve
> -------------------
>
>                 Key: IVY-1134
>                 URL: https://issues.apache.org/jira/browse/IVY-1134
>             Project: Ivy
>          Issue Type: Wish
>          Components: Ant, Core
>            Reporter: Jon Schneider
>            Priority: Minor
>
> I am trying to integrate an Eclipse Zest (GEF) Ivy resolve visualizer into IvyDE 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:
> - persist a copy (in the cache) of relevant pieces 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, and the results could only have two impacts on the rest of the tree stemming from:
> ## evictions
> ## exclusions
> WDYT?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.