Return-Path: Delivered-To: apmail-ant-notifications-archive@minotaur.apache.org Received: (qmail 15895 invoked from network); 5 Oct 2009 19:30:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Oct 2009 19:30:56 -0000 Received: (qmail 32378 invoked by uid 500); 5 Oct 2009 19:30:56 -0000 Delivered-To: apmail-ant-notifications-archive@ant.apache.org Received: (qmail 32335 invoked by uid 500); 5 Oct 2009 19:30:56 -0000 Mailing-List: contact notifications-help@ant.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ant.apache.org Delivered-To: mailing list notifications@ant.apache.org Received: (qmail 32326 invoked by uid 99); 5 Oct 2009 19:30:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Oct 2009 19:30:56 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Oct 2009 19:30:52 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7116C234C1F0 for ; Mon, 5 Oct 2009 12:30:31 -0700 (PDT) Message-ID: <1400924553.1254771031462.JavaMail.jira@brutus> Date: Mon, 5 Oct 2009 12:30:31 -0700 (PDT) From: "Jon Schneider (JIRA)" To: notifications@ant.apache.org Subject: [jira] Issue Comment Edited: (IVYDE-208) Ivy Resolve Visualizer In-Reply-To: <479967924.1254400283987.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/IVYDE-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761306#action_12761306 ] Jon Schneider edited comment on IVYDE-208 at 10/5/09 12:29 PM: --------------------------------------------------------------- Patch attached with two new icons. I just want to throw something out there so you can see it, play with it, and offer suggestions. The view is built on Eclipse GEF Zest and inspired by PDE Visualizer. Known issues: 1. Resolving. -For now, YOU MUST RUN RESOLVE on a classpath container before you try to focus on it in the viewer.- This is because the viewer is built off of the IvyNode objects in the ResolveReport. Previously, the resolve job was discarding the ResolveReport because IvyDE didn't need it. I added it to the classpath container state tentatively. Do you have any thoughts on a better way of getting the ResolveReport? I don't think Ivy stores any data about what it evicted, does it? 2. I am not happy with the code quality in the relationship between the view, form, and label provider. This thing evolved in a way that I didn't expect. I will rework it to make it cleaner. Usage: -First run resolve against a classpath container.- Then use the context menu in the view or click on the Focus toolbar icon and select the classpath container you want to view in the popup. Double clicking on a node or using the "Focus on selection" action in the context menu narrows down your view if the original view has too many dependencies to swallow at once. Still working on: -1. I would like to add error links that show you resolution conflicts and cyclic dependencies.- (added 05Oct09) 2. I still want to make the resolving configuration a label on the connecting arrows. I just don't want to clutter the view too much. I have considered just adding it on the connectors of selected nodes so it doesn't overwhelm the view. was (Author: jkschneider): Patch attached with two new icons. I just want to throw something out there so you can see it, play with it, and offer suggestions. The view is built on Eclipse GEF Zest and inspired by PDE Visualizer. Known issues: 1. Resolving. -For now, YOU MUST RUN RESOLVE on a classpath container before you try to focus on it in the viewer.- This is because the viewer is built off of the IvyNode objects in the ResolveReport. Previously, the resolve job was discarding the ResolveReport because IvyDE didn't need it. I added it to the classpath container state tentatively. Do you have any thoughts on a better way of getting the ResolveReport? I don't think Ivy stores any data about what it evicted, does it? 2. I am not happy with the code quality in the relationship between the view, form, and label provider. This thing evolved in a way that I didn't expect. I will rework it to make it cleaner. Usage: -First run resolve against a classpath container.- Then use the context menu in the view or click on the Focus toolbar icon and select the classpath container you want to view in the popup. Double clicking on a node or using the "Focus on selection" action in the context menu narrows down your view if the original view has too many dependencies to swallow at once. Still working on: 1. I would like to add error links that show you resolution conflicts and cyclic dependencies. 2. I still want to make the resolving configuration a label on the connecting arrows. I just don't want to clutter the view too much. I have considered just adding it on the connectors of selected nodes so it doesn't overwhelm the view. > 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, 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.