[
https://issues.apache.org/jira/browse/IVYDE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762599#action_12762599
]
Jon Schneider edited comment on IVYDE-208 at 10/6/09 5:49 AM:
--------------------------------------------------------------
I had already started thinking about hooking it into the
EditableModuleDescriptor class to allow us to edit versions.
I could see many of those tasks being useful. The problem I see is after each
step we would have to resolve the whole file again (which may not always be
quick). I briefly entertained the idea of trying to dynamically resolve
against just the subtree (comprised of the node you are modifying and its
dependencies) that you are modifying, but a modification anywhere in the
dependency tree affects the whole tree's evictions.
That leaves us to a batch changing strategy by which the user conducts a series
of operations and then forces the resolve and then persists the changes. I can
imagine some terribly complicated scenarios where a user changes two nodes and
one of the two modified nodes winds up being evicted as a result of the change
to the other. Then how do we decide which change goes forward and in what
order?
I feel that it has the possibility of being more complicated than beneficial
before long. Maybe if Ivy had an incremental resolve feature... See IVY-1134.
was (Author: jkschneider):
I had already started thinking about hooking it into the
EditableModuleDescriptor class to allow us to edit versions.
I could see many of those tasks being useful. The problem I see is after each
step we would have to resolve the whole file again (which may not always be
quick). I briefly entertained the idea of trying to dynamically resolve
against just the subtree (comprised of the node you are modifying and its
dependencies) that you are modifying, but a modification anywhere in the
dependency tree affects the whole tree's evictions.
That leaves us to a batch changing strategy by which the user conducts a series
of operations and then forces the resolve and then persists the changes. I can
imagine some terribly complicated scenarios where a user changes two nodes and
one of the two modified nodes winds up being evicted as a result of the change
to the other. Then how do we decide which change goes forward and in what
order?
I feel that it has the possibility of being more complicated than beneficial
before long. Maybe if Ivy had an incremental resolve feature...
> Ivy Resolve Visualizer
> ----------------------
>
> Key: IVYDE-208
> URL: https://issues.apache.org/jira/browse/IVYDE-208
> Project: IvyDE
> Issue Type: New Feature
> Reporter: Jon Schneider
> Attachments: evicted.gif, focus.gif, ivy.xml, ivyde-208.patch,
> ivyde-208.patch, ivyde-208.patch, screenshot-1.jpg, screenshot-2.jpg,
> screenshot-3.jpg, screenshot-4.jpg, screenshot-5.jpg, screenshot-6.jpg
>
>
> I am kind of excited about this one. I would like to be able to see the
> resolve report depicted graphically, showing me clearly how particular
> dependencies wound up on the classpath, what nodes got evicted, what
> dependencies a particular transitive dependency has, etc etc. Ivy can
> sometimes fall into the category of "automagically" doing so much for us on
> the classpath, that developers can take it for granted. Especially when a
> version conflict arises out of a resolution (by which two different revisions
> are resolved that aren't under the same eviction context), I see developers
> getting very confused. I hope this visualization will help them understand.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
