Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.0.beta1
    • Component/s: None
    • Labels:
      None

      Description

      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.

      1. evicted.gif
        0.3 kB
        Jon Schneider
      2. focus.gif
        0.6 kB
        Jon Schneider
      3. ivy.xml
        0.8 kB
        Jon Schneider
      4. ivyde-208.patch
        108 kB
        Jon Schneider
      5. ivyde-208.patch
        107 kB
        Jon Schneider
      6. ivyde-208.patch
        107 kB
        Jon Schneider
      7. ivyde-208.patch
        105 kB
        Jon Schneider
      8. ivyde-208.patch
        105 kB
        Jon Schneider
      9. screenshot-1.jpg
        90 kB
        Jon Schneider
      10. screenshot-2.jpg
        42 kB
        Jon Schneider
      11. screenshot-3.jpg
        68 kB
        Jon Schneider
      12. screenshot-4.jpg
        51 kB
        Jon Schneider
      13. screenshot-5.jpg
        40 kB
        Jon Schneider
      14. screenshot-6.jpg
        73 kB
        Jon Schneider
      15. ZoomableComposite.java
        2 kB
        Ivica Loncar

        Issue Links

          Activity

          Hide
          Jon Schneider added a comment - - edited

          So far I have built this visualizer with the following features:
          1. Automatic highlights of:

          • Shortest path to root
          • All paths to root
          • All callers
          • All dependencies
          • Other revisions

          2. Filtering options:

          • Hide evictions
          • Limit depth (only show up to the n-th level transitive dependency)
          • Hide selection

          3. Focusing:

          • Focus on an ivy classpath container
          • Focus on a selection

          4. Zooming
          5. Print screen
          6. Searching
          7. History
          8. Hide/Show All nodes (not sure if this is really a useful feature or not)

          Scrubbing the code a bit – patch coming soon.

          Show
          Jon Schneider added a comment - - edited So far I have built this visualizer with the following features: 1. Automatic highlights of: Shortest path to root All paths to root All callers All dependencies Other revisions 2. Filtering options: Hide evictions Limit depth (only show up to the n-th level transitive dependency) Hide selection 3. Focusing: Focus on an ivy classpath container Focus on a selection 4. Zooming 5. Print screen 6. Searching 7. History 8. Hide/Show All nodes (not sure if this is really a useful feature or not) Scrubbing the code a bit – patch coming soon.
          Hide
          Matt Benson added a comment -

          OT: I notice you've got Dozer in your screenshots. Next time Dozer is too brittle for you, remember http://morph.sourceforge.net/

          Show
          Matt Benson added a comment - OT: I notice you've got Dozer in your screenshots. Next time Dozer is too brittle for you, remember http://morph.sourceforge.net/
          Hide
          Jon Schneider added a comment - - edited

          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.

          Show
          Jon Schneider added a comment - - edited 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.
          Hide
          Ivica Loncar added a comment -

          Nice work. I was prepared to do something similar, but now there is no need to re-invent the wheel. Thanks.

          Couple of suggestions/requests:

          • I would like this feature to run on eclipse 3.4.x since all of our clients that use ivy also use Rational development tools
          • Users should be able to choose ivy configuration that should be visualized. When users add multiple ivy containers to the classpath they see classpath container named like: "ivy.xml [conf1]" but in the visualizer there are multiple "Project name (ivy.xml)" entries. I think the label should be "Project name (ivy.xml/conf1)".

          There are "Previous view" and "Go forward one plugin" icons in the view toolbar but I can't see the icons and I do have org.eclipse.ui enabled in the target platform.
          Do you know why these shared images are not loading? What could be missing?

          Show
          Ivica Loncar added a comment - Nice work. I was prepared to do something similar, but now there is no need to re-invent the wheel. Thanks. Couple of suggestions/requests: I would like this feature to run on eclipse 3.4.x since all of our clients that use ivy also use Rational development tools Users should be able to choose ivy configuration that should be visualized. When users add multiple ivy containers to the classpath they see classpath container named like: "ivy.xml [conf1] " but in the visualizer there are multiple "Project name (ivy.xml)" entries. I think the label should be "Project name (ivy.xml/conf1)". There are "Previous view" and "Go forward one plugin" icons in the view toolbar but I can't see the icons and I do have org.eclipse.ui enabled in the target platform. Do you know why these shared images are not loading? What could be missing?
          Hide
          Jon Schneider added a comment -

          Ivica,

          Thanks for the feedback.

          • I developed this on 3.4 and have been using it in RAD 7.5.3. You do need to install Zest separately on most 3.4 installations I believe.
          • I changed the text of the classpath containers in the dialog box per your suggestion.
          • I moved the call to org.eclipse.ui.ISharedImages, thinking that maybe somehow the view class was getting loaded before a workbench was available from PlatformUI? Honestly, I'm not the most experienced Eclipse plugin developer. Please let me know if that works for you. I see the images here without trouble on Eclipse 3.4, 3.5, and RAD 7.5.3.
          Show
          Jon Schneider added a comment - Ivica, Thanks for the feedback. I developed this on 3.4 and have been using it in RAD 7.5.3. You do need to install Zest separately on most 3.4 installations I believe. I changed the text of the classpath containers in the dialog box per your suggestion. I moved the call to org.eclipse.ui.ISharedImages, thinking that maybe somehow the view class was getting loaded before a workbench was available from PlatformUI? Honestly, I'm not the most experienced Eclipse plugin developer. Please let me know if that works for you. I see the images here without trouble on Eclipse 3.4, 3.5, and RAD 7.5.3.
          Hide
          Ivica Loncar added a comment - - edited

          Now I can see icons but they look way too small. They aren't 16x16. I still can't figure out why. Probably has something with my setup.

          More ideas:

          • zoom in/out using ctrl+mouse scroll
          • search should focus on found items, there should be a convinient method to select next/previous item

          Btw. I have been playing with Zest and found out that there is a thumbnail previewer. Instead of scrollbars we could use a thumbnail.

          Sample code:

           private static class ZoomableComposite extends Composite {
                  FigureCanvas thumbnail;
                  ScrollableThumbnail tb;
          
                  public ZoomableComposite(Composite parent, int style) {
                      super(parent, style);
                      this.setLayout(new FormLayout());
                      createZoomableCanvas(this);
                  }
                  
                  public void setGraph(Graph graph) {
                      if (graph.getParent() != this) {
                          throw new AssertionError("Graph must be a child of this zoomable composite.");
                      }
                      createContents(graph);
                      tb.setViewport(graph.getViewport());
                      tb.setSource(graph.getContents());
                  }
          
                  private void createZoomableCanvas(Composite parent) {
                      FormData data = new FormData();
                      data.top = new FormAttachment(100,-130);
                      data.left = new FormAttachment(100,-130);
                      data.right = new FormAttachment(100,-30);
                      data.bottom = new FormAttachment(100,-30);
                      
                      thumbnail = new FigureCanvas(parent, SWT.NONE);
                      thumbnail.setBackground(ColorConstants.white);
                      thumbnail.setLayoutData(data);
                      
                      tb = new ScrollableThumbnail();
                      tb.setBorder(new LineBorder(1));
                      thumbnail.setContents(tb);
                  }
          
                  private void createContents(Control control) {
                      FormData data = new FormData();
                      data.top = new FormAttachment(0,0);
                      data.left = new FormAttachment(0,0);
                      data.right = new FormAttachment(100,0);
                      data.bottom = new FormAttachment(100,0);
                      control.setParent(this);
                      control.setLayoutData(data);
                  }
                  
              }
          

          One can use it like this:

              private void createGraphSection(Composite parent) {
                  Section section = this.toolkit.createSection(parent, Section.TITLE);
                  ZoomableComposite zoomableComposite = new ZoomableComposite(section, SWT.NONE);
                  viewer = new InternalGraphViewer(zoomableComposite, SWT.NONE);
                  viewer.getGraphControl().setVerticalScrollBarVisibility(FigureCanvas.NEVER);
                  viewer.getGraphControl().setHorizontalScrollBarVisibility(FigureCanvas.NEVER);
                  zoomableComposite.setGraph((Graph)viewer.getControl());
                  section.setClient(zoomableComposite);
              }
          

          Of course if you need more screen real-estate you can just remove the section:

              private void createGraphSection(Composite parent) {
                  ZoomableComposite zoomableComposite = new ZoomableComposite(parent, SWT.NONE);
                  viewer = new InternalGraphViewer(zoomableComposite, SWT.NONE);
                  viewer.getGraphControl().setVerticalScrollBarVisibility(FigureCanvas.NEVER);
                  viewer.getGraphControl().setHorizontalScrollBarVisibility(FigureCanvas.NEVER);
                  zoomableComposite.setGraph((Graph)viewer.getControl());
              }
          
          Show
          Ivica Loncar added a comment - - edited Now I can see icons but they look way too small. They aren't 16x16. I still can't figure out why. Probably has something with my setup. More ideas: zoom in/out using ctrl+mouse scroll search should focus on found items, there should be a convinient method to select next/previous item Btw. I have been playing with Zest and found out that there is a thumbnail previewer. Instead of scrollbars we could use a thumbnail. Sample code: private static class ZoomableComposite extends Composite { FigureCanvas thumbnail; ScrollableThumbnail tb; public ZoomableComposite(Composite parent, int style) { super (parent, style); this .setLayout( new FormLayout()); createZoomableCanvas( this ); } public void setGraph(Graph graph) { if (graph.getParent() != this ) { throw new AssertionError( "Graph must be a child of this zoomable composite." ); } createContents(graph); tb.setViewport(graph.getViewport()); tb.setSource(graph.getContents()); } private void createZoomableCanvas(Composite parent) { FormData data = new FormData(); data.top = new FormAttachment(100,-130); data.left = new FormAttachment(100,-130); data.right = new FormAttachment(100,-30); data.bottom = new FormAttachment(100,-30); thumbnail = new FigureCanvas(parent, SWT.NONE); thumbnail.setBackground(ColorConstants.white); thumbnail.setLayoutData(data); tb = new ScrollableThumbnail(); tb.setBorder( new LineBorder(1)); thumbnail.setContents(tb); } private void createContents(Control control) { FormData data = new FormData(); data.top = new FormAttachment(0,0); data.left = new FormAttachment(0,0); data.right = new FormAttachment(100,0); data.bottom = new FormAttachment(100,0); control.setParent( this ); control.setLayoutData(data); } } One can use it like this: private void createGraphSection(Composite parent) { Section section = this .toolkit.createSection(parent, Section.TITLE); ZoomableComposite zoomableComposite = new ZoomableComposite(section, SWT.NONE); viewer = new InternalGraphViewer(zoomableComposite, SWT.NONE); viewer.getGraphControl().setVerticalScrollBarVisibility(FigureCanvas.NEVER); viewer.getGraphControl().setHorizontalScrollBarVisibility(FigureCanvas.NEVER); zoomableComposite.setGraph((Graph)viewer.getControl()); section.setClient(zoomableComposite); } Of course if you need more screen real-estate you can just remove the section: private void createGraphSection(Composite parent) { ZoomableComposite zoomableComposite = new ZoomableComposite(parent, SWT.NONE); viewer = new InternalGraphViewer(zoomableComposite, SWT.NONE); viewer.getGraphControl().setVerticalScrollBarVisibility(FigureCanvas.NEVER); viewer.getGraphControl().setHorizontalScrollBarVisibility(FigureCanvas.NEVER); zoomableComposite.setGraph((Graph)viewer.getControl()); }
          Hide
          Jon Schneider added a comment -

          Thumbnail Previewer

          Good work on the thumbnail previewer! I like it. It is included in the most recent patch.

          Mouse Scroll Zoom

          I have some bad news on the mouse scroll zoom functionality. We would use this method from the AbstractZoomableViewer:

          public abstract class AbstractZoomableViewer extends StructuredViewer {
          	public void zoomTo(int x, int y, int width, int height) {
          		Rectangle r = new Rectangle(x,y,width,height);
          		if (r.isEmpty()) {
          			getZoomManager().setZoomAsText("100%");
          		} else {
          			getZoomManager().zoomTo(r);
          		}
          	}
          ...
          }
          

          Unfortunately, the body of ZoomManager.zoomTo(..) is commented out, so this method really does nothing. ZoomManager has other methods that could be used, but it is a restricted access class. I don't see a way around this at this point in time.

          Search behavior

          Currently search highlights matching nodes. Since the viewer currently can only view one root node at a time, I don't think it would make sense to change the default behavior to focusing over highlighting. What use cases do you have in mind that would benefit from focusing over highlighting? The use cases I had in mind for search were:

          1. Highlighting a particular organization's contribution to the resolved classpath entries.
          2. Highlighting multiple revisions of a particular module name.

          "Focus on file" behavior changed

          What I said earlier about having to resolve before focusing is no longer true. The focus action looks for a resolve report on the container state. If a report is not found, it launches a resolve and views the results after the resolve is complete. This process takes place in a background job; it does not block the workspace.

          Show
          Jon Schneider added a comment - Thumbnail Previewer Good work on the thumbnail previewer! I like it. It is included in the most recent patch. Mouse Scroll Zoom I have some bad news on the mouse scroll zoom functionality. We would use this method from the AbstractZoomableViewer: public abstract class AbstractZoomableViewer extends StructuredViewer { public void zoomTo( int x, int y, int width, int height) { Rectangle r = new Rectangle(x,y,width,height); if (r.isEmpty()) { getZoomManager().setZoomAsText( "100%" ); } else { getZoomManager().zoomTo(r); } } ... } Unfortunately, the body of ZoomManager.zoomTo(..) is commented out, so this method really does nothing. ZoomManager has other methods that could be used, but it is a restricted access class. I don't see a way around this at this point in time. Search behavior Currently search highlights matching nodes. Since the viewer currently can only view one root node at a time, I don't think it would make sense to change the default behavior to focusing over highlighting. What use cases do you have in mind that would benefit from focusing over highlighting? The use cases I had in mind for search were: Highlighting a particular organization's contribution to the resolved classpath entries. Highlighting multiple revisions of a particular module name. "Focus on file" behavior changed What I said earlier about having to resolve before focusing is no longer true. The focus action looks for a resolve report on the container state. If a report is not found, it launches a resolve and views the results after the resolve is complete. This process takes place in a background job; it does not block the workspace.
          Hide
          Ivica Loncar added a comment - - edited

          Scroll

          I thought it would be nice to have scrollable zoom but I guess we can live without it for now.

          Search behaviour

          Some of our projects have a lot of dependencies and graphs tend to get wide so It's hard to find some of the websphere jars if you don't remember exact name.
          I agree... it's not that important feature.

          Graph nodes tend to get wide and occupy a lot of horizontal space and much less vertical space. We could make them a bit narrower and taller.

          "Focus on file" behaviour

          What can be done with configurations that are not exposed as eclipse classpath containers? Can we get them visualized also?

          Show
          Ivica Loncar added a comment - - edited Scroll I thought it would be nice to have scrollable zoom but I guess we can live without it for now. Search behaviour Some of our projects have a lot of dependencies and graphs tend to get wide so It's hard to find some of the websphere jars if you don't remember exact name. I agree... it's not that important feature. Graph nodes tend to get wide and occupy a lot of horizontal space and much less vertical space. We could make them a bit narrower and taller. "Focus on file" behaviour What can be done with configurations that are not exposed as eclipse classpath containers? Can we get them visualized also?
          Hide
          Jon Schneider added a comment - - edited

          Added configuration conflict detection algorithm and highlighting. See screenshot-6 for a visual overview of the additions. I also attached an example ivy.xml file that has conflicts so you can see the effect yourself.

          Concerning wide graphs, I agree. My graphs sometimes get very wide as well. I wonder if I can reorient the nodes on a 45 degree angle (probably not)... Maybe a newline between org and name would help narrow the graph somewhat. I'll play around with it. This phenomenon led me to try to make the thumbnail previewer a little shorter and wider as well to save on screen real estate. I fiddled with it for a half hour and couldn't figure out a way to accomplish it.

          Concerning files that are not associated with containers, I heard the same question from developers here. I am a little uncomfortable moving forward on this until I hear feedback from Nicolas, because I am already somewhat abusing the IvyResolveJob (at least using it in a way it wasn't intended for). We may have to do a little refactoring in other parts of the plugin to expose the resolve capability outside of the Job if we are going to pursue this. I totally agree that it is an important feature, though.

          Show
          Jon Schneider added a comment - - edited Added configuration conflict detection algorithm and highlighting. See screenshot-6 for a visual overview of the additions. I also attached an example ivy.xml file that has conflicts so you can see the effect yourself. Concerning wide graphs, I agree. My graphs sometimes get very wide as well. I wonder if I can reorient the nodes on a 45 degree angle (probably not)... Maybe a newline between org and name would help narrow the graph somewhat. I'll play around with it. This phenomenon led me to try to make the thumbnail previewer a little shorter and wider as well to save on screen real estate. I fiddled with it for a half hour and couldn't figure out a way to accomplish it. Concerning files that are not associated with containers, I heard the same question from developers here. I am a little uncomfortable moving forward on this until I hear feedback from Nicolas, because I am already somewhat abusing the IvyResolveJob (at least using it in a way it wasn't intended for). We may have to do a little refactoring in other parts of the plugin to expose the resolve capability outside of the Job if we are going to pursue this. I totally agree that it is an important feature, though.
          Hide
          Ivica Loncar added a comment -

          I'm thinking about this resolution visualizer and I find more uses for it as an additional page in ivy.xml editor.

          Making ivy resolution visualizer part of the ivy.xml editor could make the view available for additional "visual" tasks like:

          • exclude dependency
          • remove transient dependencies
          • exploration of different versions, etc.

          What do you think?

          Show
          Ivica Loncar added a comment - I'm thinking about this resolution visualizer and I find more uses for it as an additional page in ivy.xml editor. Making ivy resolution visualizer part of the ivy.xml editor could make the view available for additional "visual" tasks like: exclude dependency remove transient dependencies exploration of different versions, etc. What do you think?
          Hide
          Jon Schneider added a comment - - edited

          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 this: 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 a subtree (comprised of the node you are modifying and its dependencies), 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.

          Show
          Jon Schneider added a comment - - edited 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 this: 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 a subtree (comprised of the node you are modifying and its dependencies), 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 .
          Hide
          Jon Schneider added a comment - - edited

          Fixed eviction code to correctly display evictions and conflicts. Refactored ResolveReport adapter code out of the model. Added tooltips to connections to show which caller configurations caused a node to be resolved.

          Show
          Jon Schneider added a comment - - edited Fixed eviction code to correctly display evictions and conflicts. Refactored ResolveReport adapter code out of the model. Added tooltips to connections to show which caller configurations caused a node to be resolved.
          Hide
          Jon Schneider added a comment -
          • Added a refresh action for the currently displayed view.
          • Bug fix for displaying evicted nodes.
          • Removed multiple selection capability of the container selection dialog.
          Show
          Jon Schneider added a comment - Added a refresh action for the currently displayed view. Bug fix for displaying evicted nodes. Removed multiple selection capability of the container selection dialog.
          Hide
          Nicolas Lalevée added a comment -

          I finally took time to review the patch: great job Jon ! I don't know at all the Zest API but it looks good

          I think there is a legal issue here though. All patches have been properly granted for inclusion in ASF works under the ASL. But it includes work from Ivica Loncar in his comment of 03/Oct/09 10:07 PM which hasn't any license.
          So Ivica could you please attach a file with the code you posted and grant license to ASF for inclusion in ASF works ?

          A little question: why the package containing ILabelDecoratorAlgorithm and its implementation is named "label" ?

          And a nitpicking remark: at the beginning of using it I was searching of how to link the view with a ivy.xml. I think it would help to have a "Show in Resolve Vizualizer" in the context menu of the project. And also maybe change the icon in view: the current icon (a magnifying glass) made me think a search, rather than "open"; probably an icon of an opened folder would better fit.

          Then about the dependency on Zest, should we make it required ? I didn't found the requirement of Zest itself. IvyDE today is expected to support Eclipse 3.2, but this could change if necessary, we may want to ask IvyDE users too. I don't know if it is even possible to have an optional view depending of some dependency, maybe by making it a separate plugin...

          Show
          Nicolas Lalevée added a comment - I finally took time to review the patch: great job Jon ! I don't know at all the Zest API but it looks good I think there is a legal issue here though. All patches have been properly granted for inclusion in ASF works under the ASL. But it includes work from Ivica Loncar in his comment of 03/Oct/09 10:07 PM which hasn't any license. So Ivica could you please attach a file with the code you posted and grant license to ASF for inclusion in ASF works ? A little question: why the package containing ILabelDecoratorAlgorithm and its implementation is named "label" ? And a nitpicking remark: at the beginning of using it I was searching of how to link the view with a ivy.xml. I think it would help to have a "Show in Resolve Vizualizer" in the context menu of the project. And also maybe change the icon in view: the current icon (a magnifying glass) made me think a search, rather than "open"; probably an icon of an opened folder would better fit. Then about the dependency on Zest, should we make it required ? I didn't found the requirement of Zest itself. IvyDE today is expected to support Eclipse 3.2, but this could change if necessary, we may want to ask IvyDE users too. I don't know if it is even possible to have an optional view depending of some dependency, maybe by making it a separate plugin...
          Hide
          Ivica Loncar added a comment - - edited

          ZoomableComposite with ASF license.

          I have just copy/pasted the code in comment. Is this ok?

          Show
          Ivica Loncar added a comment - - edited ZoomableComposite with ASF license. I have just copy/pasted the code in comment. Is this ok?
          Hide
          Nicolas Lalevée added a comment -

          This is then ok for me to be committed, thanks Ivica !

          Show
          Nicolas Lalevée added a comment - This is then ok for me to be committed, thanks Ivica !
          Hide
          Jon Schneider added a comment -

          Nicolas,

          I intend to add the menu shortcut and do a little more refactoring before it is all done.

          I think Zest requires Eclipse 3.4+, which would be quite a shift. How do you want to go about asking IvyDE users?

          Show
          Jon Schneider added a comment - Nicolas, I intend to add the menu shortcut and do a little more refactoring before it is all done. I think Zest requires Eclipse 3.4+, which would be quite a shift. How do you want to go about asking IvyDE users?
          Hide
          Nicolas Lalevée added a comment -

          The IvyDE users are on the ivy-user mailing list. Probably we should have a first mail on ant-dev to ask what developers thinks about it.

          Show
          Nicolas Lalevée added a comment - The IvyDE users are on the ivy-user mailing list. Probably we should have a first mail on ant-dev to ask what developers thinks about it.
          Hide
          Nicolas Lalevée added a comment -

          I finally integrated the patch into the trunk. I made it a separate plugin so it can be optionally installed, since it requires additional dependencies (zest).

          Show
          Nicolas Lalevée added a comment - I finally integrated the patch into the trunk. I made it a separate plugin so it can be optionally installed, since it requires additional dependencies (zest).

            People

            • Assignee:
              Nicolas Lalevée
              Reporter:
              Jon Schneider
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development