[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [buckminster-dev] Dependency Visualization
|
Hi Ed,
First of all, I have no aversion to EMF. But the model-driven approach
does bring a lot of overhead to enable all that meta-modeling. Must be
the 'meta' thing ;)
I'm not so sure you're response is that honest in terms of installation
pain. Installing WTP can be an unbelievable pain, and I'm sure I'm not
the only one saying that. The amount of times I just got stuck with an
Eclipse set-up which wouldn't install additional plug-ins because of
EMF-related plug-in mismatches... I simply can't count those instances
anymore. You'll probably say that's not EMF's fault per se, but EMF is
always implicated.
Because EMF is high up in the dependency hierarchy, it is one of those
projects which exposes Eclipse dependency problems the most. You're
probably referring to 'just EMF', but I'm talking about getting those
EMF-based projects to get along, which has been a *real* pain.
Building EMF with Buckminster is one thing, but if you already need an
instance of EMF before you can do that? How about those circular build
dependencies? Back to the dark woods of the PDE build?
Perhaps I better start a fork, right here and now and maintain a bit of
peace of mind...
Best regards,
Dann
Ed Merks wrote:
Dann,
Naturally I don't think of EMF has a behemoth. :-P
I suppose if you consider the all-in-one-sdk zip, which includes each
and every fine-grained EMF feature along with the fine-grained XSD
features (that you don't need), at grand total of 27MB, you might
consider that a behemoth. But then, I'm not sure what that makes
Eclipse itself at 150MB+. The behemoth that chokes all behemoths?
Surely you're not suggesting that an additional < 20% of downloads would
be the end of the world? The core EMF runtime is tiny, i.e., 2 MB, and
even the EMF features needed to support viewing are tiny, a few more
MB. We're talking tools at this point, not runtime, at Thomas pointed
out, though I'm not sure that matters to you...
I'm just not sure at which point the "terrible pain" kicks in though...
Of course p2 changes the game entirely. Only the features you actually
need need be installed...
Maybe you could elaborate on the incredibly painful experiences you've
had with installing EMF. Is it the download rate that's the problem?
The long unzip times? Something else? Many millions of people are
installing EMF, even just to install WTP, and I've not heard about a
great many incredibly painful events. People tend to complain loudly so
I'm pretty sure I would have heard about painful things...
At some point in the future, i.e., the e4 future, EMF will already be in
the platform installation itself, because it's being used to model the
workbench, so you're bound to be unhappy eventually if EMF itself makes
you unhappy. I suppose perhaps eventually you just won't notice EMF's
presence...
I hope you're sitting down already. Maybe lying down would be better. :-P
I've seen many arguments about avoid bloat. Unfortunately they usually
involve each project inventing its own solution to the same common
problem. The net result is that there end up being dozens of solutions
to exactly the same problem. That's also bloat; the worst kind. It's
ironic to me that avoiding bloat causes bloat, but that always seems to
be the way...
Probably you need to get over your aversion, or be more specific about
it...
Dann Martens wrote:
Well yes,
I don't really want to go through the pain of having to install the
EMF plug-ins (ouch!) just to use Buckminster. I really hope you're not
going on that path because that sounds really terrible. I hope P2
changes things, but installing EMF has been an incredible pain up to
now. Really, that's en emphatic no-no; I'd be really unhappy to see
EMF dependencies pulled in, just to use Buckminster. Actually, I have
to sit down, now. The idea of all that bloat is making my tummy ache.
Zest is just a wrapper around draw2D, and that's a totally different
matter.
Best regards,
Dann
Thomas Hallgren wrote:
Hi Dann,
A Buckminster runtime is one thing, the tools used to maintain it
another. The runtime should be kept mean and lean, that's for sure,
and I think that is what your concern is about?
One thing that I've learned about EMF the last couple of weeks is
that the runtime instances that it creates are very optimized and in
many cases far more optimal then the Java classes that people
normally write. Booleans are grouped together as bits in integer
values, same thing with enums. I'm sure there's a lot of other
optimizations going on as well that I haven't found yet. All in all,
I'm quite convinced that using EMF to describe things like our CSPEC,
RMAP, etc. will give us a smaller, less error prone, and more
efficient runtime. The actual models themselves, visualized
graphically using the ecore tools diagram editor, will become
valuable contributions to the documentation.
Then we have the tools surrounding it all. Editors for the model for
instance. We get them for free with EMF. The generated editor can be
extended and improved a lot of course, but event the bare-bone
generated thing beats the hell out of using a text editor on XML
documents. The generated editors are also very well crafted. Mean and
lean. Easy to extend and modify.
IMO EMF will become (and in some respect already is) a very valuable
tool for us. Not sure I see why you'd think otherwise.
I have no experience with Zest but from the looks of it, it brings us
a very good dependency visualization and that is something that we
have been longing for for some time now. Installing it will be
optional of course.
Regards,
Thomas Hallgren
Dann Martens wrote:
Wait a minute,
EMF? Zest, sure, but I would hope we could keep that behemoth out of
there, we're talking a configuration management tool here.
Best regards,
Dann
Guillaume Chatelet wrote:
Wow Johannes ! This looks great : )
UI is actually an issue in Buckminster and EMF + Zest will do a
good job here. Very cool : )
Best regards,
Guillaume
On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@xxxxxxxxx
<mailto:mail@xxxxxxxxx>> wrote:
Hi,
as discussed in
http://dev.eclipse.org/newslists/news.eclipse.tools.buckminster/msg01102.html
I started working on a zest based component dependency viewer for
buckminster.
I just finished an early prototype and thought it's enough to get
at least an idea and ask you guys what kinds of features you'd
like
to see in it.
Currently this is (for sake of simplicity) registered as an editor
for previously saved .bom files.
It consists of 3 areas
-navigation tree that shows a tree of the component dependencies
and is used to drill down on the graph. The selection is linked to
the graph viewer so if you select a component in the tree, only
this
specific subtree is revealed in the graph.
-graph viewer. This is very basic at the moment. It shows the
dependency graph with some icons depending on the component
type and
highlights the direct dependencies of the selected component.
Unresolved nodes are shown in red, a double-click on a node
reveals
the node's cspec and that's about it :)
-settings section. This section lets you choose between some
layout
algorithms and filters (only platform component filter so far).
Filters are applied to both the navigation tree and the graph
viewer.
I came up with the following things that should be added:
-better highlighting
-tooltips and properties view that reveal more details of each
component
-smart highlighting of paths through the graph (shortest path to
root request for example)
-regex based filter (black and white list filter)
-dependency reports generated from a bom with some nice pictures
-zooming
-image export
Now I'd be very interested to hear what's on your wish-list for
dependency visualization, so that I can plan on the real
implementation.
Attached is a screenshot and a bundle.jar including source code.
Just throw it in your dropins folder to try, but make sure that
zest
is installed.
Keep in mind, this is just an early prototype for demonstration
and
my first steps with zest, so the code is super ugly at the
moment...
Best regards,
Johannes
_______________________________________________
buckminster-dev mailing list
buckminster-dev@xxxxxxxxxxx <mailto:buckminster-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/buckminster-dev