Dann,
Comments below.
Dann Martens wrote:
Hi Ed,
First of all, I have no aversion to EMF.
It sounds like one though...
But the
model-driven approach does bring a lot of overhead to enable all that
meta-modeling.
Overhead? Meta-modeling?
Must be
the 'meta' thing ;)
I'm not a big fan of the word meta. Probably you know that, but
perhaps you don't... The model of a model is a model...
I'm not so sure you're response is that honest in terms of installation
pain.
Honesty is a fundamental quality I hold dear. Very few people question
my honesty. Certainly it's your prerogative to do that, and in that
case, I'll reserve the right to question yours.
Installing
WTP can be an unbelievable pain, and I'm sure I'm not the only one
saying that.
I've not installed WTP, so personally I have no idea. I've only ever
install the platform and then I bootstrap EMF (and a dozen or more
other projects) from CVS, so in all honesty, I can say I have little
experience installing anything...
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...
Again, I have no idea what you mean by "install". You mean update
manager, unzipping files, p2, or what?
I
simply can't count those instances anymore.
I can imagine the pain, though I've not experienced it. Of course if
installing one more thing on top of the platform is a huge pain, then
even installing Buckminster as one additional thing must be painful
already. If not, why not? I suppose you mean installing two different
things each of which depends on EMF, but instead you might want to
blame that pain on bad plugin version ranges, the platform's treatment
of them, and the universal belief that they represent goodness, rather
than blame EMF...
You'll
probably say that's not EMF's fault per se, but EMF is always
implicated.
I've very used to being a scapegoat.
http://ed-merks.blogspot.com/2009/03/on-being-scapegoat.html
In the end though, there's little of substance in the scapegoating, so
it's just a form of entertainment for me. Folly in other words...
Because EMF is high up in the dependency hierarchy, it is one of those
projects which exposes Eclipse dependency problems the most.
Or low down, depending on which direction you grow. But yes, being a
foundation component makes for being a great scapegoat. It seems as if
you're arguing to avoid having foundation components because that way
we can avoid seeing dependency problems. That's clearly a questionable
argument.
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.
I guess that's a pain, but since you have to do that anyway, or so it
seems, I'm not sure how your problem got worse. In any case, you've
not provided one iota of substance. Just scapegoating EMF and finger
pointing in the typical way that's grown tiresome over the years.
Building EMF with Buckminster is one thing,
A totally unrelated thing in fact...
but if
you already need an instance of EMF before you can do that?
Isn't bootstrapping fun. That's irrelevant to you though, since you
aren't building EMF. Why bring it up?
In any case, one needs an instance of EMF to generate EMF. That sounds
impossible?
How
about those circular build dependencies?
I guess it's impossible although we do this all the time.
Back
to the dark woods of the PDE build?
I guess PDE build is the dark wood, but I don't see the connection.
Perhaps I better start a fork, right here and now and maintain a bit of
peace of mind...
I guess so. Peace of mind is a valuable commodity so it's probably
worth just about any price.
In any case, I don't think you've done a good job arguing you have no
aversions. Your line of reasoning would seem to argue that it's a bad
idea to have common foundation components because there are dependency
problems when many projects depend on such foundation components.
Perhaps we ought to focus on those so they're fixed rather than throw
away good architecture concepts...
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
|
