[
https://issues.apache.org/jira/browse/IVY-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776443#action_12776443
]
Jon Schneider edited comment on IVY-1134 at 11/11/09 1:20 PM:
--------------------------------------------------------------
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
\
-> 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.
was (Author: jkschneider):
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.
