ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Schneider (JIRA)" <j...@apache.org>
Subject [jira] Commented: (IVY-1134) Incremental Resolve
Date Wed, 11 Nov 2009 13:19:39 GMT

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


Mime
View raw message