Community
Participate
Working Groups
From a chat transcript with Greg: Was wondering if pde (or something I can get that plugs into pde provided i have GEF installed) that will allow me to graphically render a map of plugin dependency & features etc. It would me really helpful if eclipse had something like this. It also helps you visually spot where you have perhaps dependencies on non api (could highlight those in red), and for product teams that depend on each other or component teams that depend on each other it would massively help see whats what GEF is on eclipse.org as well so i was thinking it would be handy to have some plugins available on pde component site one could grab and plug in provided u also had gef installed. its tricky building products and seeing the dependencies you have and collectively we want to get to better platform layering so stuff like these visualizations and dependencies are helpful if u have filtering it helps negate complexity, and zooming (which gef provides free) its like a schematic of a complex circuit I can see it starting at the top with feature to feature dependencies (providing that features are used) Then i can say, ok for my features (or feature) show me what i am pulling in or i could pick a set of plugins and say show me its graph.... i could envision using that in a number of ways 1. pick a component and see what it pulls in 2. pick a set of components (plugins) and see what it pulls in 3. Or pick perhaps just our model plugins and make sure they only pull in other model ones and not ui ones etc yes, this is more of a product planning/analysis tool than everyday developer's tool it should be in the center of your attention, not an auxilliary view that you can have on a side as you work possibly maximized i could also see a team lead using it to keep an eye on his dependency world. Last question for you If I have eclipse loaded up...is there a way i can get a printout (text file) of a dependency graph of plugins. And ideally something like: plugin x feature a uses plugin z feature b another way this stuff is really handy is when refactoring plugins as you try and drive out common components, or platforms.
Nice. +1
There is "Plig-in Dependencies" view that shows dependencies tree and allow to drill down. Perhaps it would make sense to extend it somehow, e.g. show details for selected plugins in standar "Properties" view. Current implementation also does not provide groupping by "features", though "features" is kind of artificial thing, which probbly only relevant for update manager... Another potentially interesting thing could be to generate graph starting from selecting node shown in "Plug-in Dependencies" view.
This is one feature that we would really like to have and, based on EclipseCon feedback, so does the community. When he is not busy working on PhD thesis, teaching and taking care of his new baby, Ian has managed to pull together an impressive initial prototype: http://mea-bloga.blogspot.com/2007/03/visualization-in-eclipse-sdk.html Considering the lack of graphing support in the Eclipse SDK, it is currently not possible to have such a function as part of PDE/UI. We will therefore move it into the PDE/Incubator area to do more work/investigation, and hopefully it can graduate into the sdk in the near future. cc Top Contributor winner Kim Peter, as she likes this kind of stuff.
Thanks for bringing this bug report up Wassim. As Wassim pointed out, I have been working on this problem in the PDE incubator. For part of my graduate work, I created a directed graph widget to facilitate the easy creation of graph visualizations (http://www.eclipse.org/mylar/zest.php). The graph widget is built on GEF / Draw2D. I used the widget to create some views of plug-in dependencies with different filter options. I haven’t covered all the features requested, but I think the approach has potential. However, there is a problem with dependencies in the SDK. Because my directed graph widget depends on GEF, the view cannot be part of platform. I think there are 4 different avenues we can take: 1) Leave the dependencies as is, and ship the view as an additional bundle. 2) Work with platform team to include GEF within the SDK 3) Refactor my work to remove the dependency on GEF (using only Draw2D) and work with the platform to include Draw2D with the SDK 4) Refactor my work to remove all dependencies on GEF and Draw2D and built the view using the SWT Canvas. I don’t think (4) has much practicality. In order to build a decent view (and especially keep the notion of a directed graph widget), we need a hierarchy of figures, connections, connection anchors, mouse / keyboard events for figures, hit tests, etc… basically all the things Draw2D gives us. I don’t think it makes sense to reproduce Randy’s work, considering he did an excellent job with Draw2D (and the Jar is only 474 K). (1) May make sense; however, it sounds like the community wants the view to be a standard component not an additional download. Plus, if this works, we could potentially create additional visualizations for others. I don’t think we have a good enough reason to include GEF within the SDK (2). While I agree GEF is a *great* framework, our particular use case only calls for graph visualization. If someone requested a UML diagram editor in the platform, that would be a different story, but for now, it doesn’t seem reasonable to ask the SDK to ship with GEF so we can draw a graph. This leaves (3). It would take some time to decouple my view from GEF (and just use Draw2D), but I would consider doing this if we though it would solve this problem. What are others thoughts on making Draw2D part of the platform? Did I miss any options?
Well for me it doesn't have to be in the platform. I want to look at my RCP-Projects, visualize the dependencies, print them out and discuss potential problems with my team. So for me a dependency on PDE/GEF/<something else> is not a big deal. Although I must admit I would like less dependencies. ;-) How about releasing as it is right now and refactoring it later?
Ian, since we are in the incubator, I suggest that you depend on whatever it is you need to depend on (GEF/draw2d, etc.), and get something out there for people to play with and provide feedback. We could worry about minimizing dependencies later.
When I mentioned the need for plugin dependency graph visualization at the Blue Sky BOF, I wasn't aware of the incubator project. I'm excited to try that out. Personally, it's not a big deal for me if I this visualization isn't included in PDE because I *always* have GEF installed and don't mind installing other plugins on top of it. However, I think there are other people out there that might want to visualize these dependencies who don't feel the same way. In any case, thanks to everyone for increasing the visibility of this issue.
Using the keyword [pde viz] for all plugin dependency visualization bugs.
Ian, is this issue resolved?
Not sure if this is the proper place for this... if not, please let me know where the proper place is! Where can one find information regarding future development of the PDE Visualization Tool (which I love). What's the time frame for moving out of incubator? What future enhancements are planned post-3.5?
(In reply to comment #10) > Not sure if this is the proper place for this... if not, please let me know > where the proper place is! > > Where can one find information regarding future development of the PDE > Visualization Tool (which I love). What's the time frame for moving out of > incubator? What future enhancements are planned post-3.5? > Thanks for the kind words.. Chris has been hacking on the tool lately, and we are looking at what is involved with moving it out of incubation. From an IP view, there are no problems (I wrote all the code and it only depends on other non-incubating projects). Right now it is more of a political issue (how can the platform host something that depends on Zest (which is in tools)). Lucky for us, this is already being done with ECF, p2 and the platform, so a precedence exists. As for your question about future enhancements, if we are lucky, we will get a student to help work on it. :)
*** Bug 255418 has been marked as a duplicate of this bug. ***
*** Bug 284588 has been marked as a duplicate of this bug. ***
I have started this for M2 I have created a build via Athena CBI: https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-pde.visualization-1.0-Helios/ I have published the first build here: http://download.eclipse.org/eclipse/pde/visualization/downloads/N200908192218/ The update site is: http://download.eclipse.org/eclipse/pde/visualization/updates There's a couple things to do before we are done with this. We need to enhance the build to produce a valid categorization of the feature. I would also like to have the PDE team do a cursory code review. Everything is marked internal at the moment.
Changing target milestone to 3.6 as M2 is upon us.
I'll make sure that this happens in M3 We have a build in place already. We need to update our website.
This is finally done for M3. We have builds now on build.eclipse.org https://build.eclipse.org/hudson/view/Athena%20CBI/job/cbi-pde.visualization-1.0-Helios/ We now publish those builds to a repo http://download.eclipse.org/eclipse/pde/visualization/updates I updated the PDE Downloads page with a link to the repository: http://www.eclipse.org/pde/downloads Enjoy.
