So here's my comments on the second video, Customizing and Extending the Visual Design Experience. Notice that the comments really are based on just watching the videos, not on working or playing with anything.

I guess the stuff isn't really finished yet, but if Microsoft continues down this road, this stuff will be *very* interesting.

Also, if you're an Eclipse E4 person: take a look at this stuff - this is very related!

Based on Videos - didn't work with tool!
E4 - look at that!

So here we go.

Don Box calls stuff "Data Driven". That sounds more like I would call what they do...

Don Box, as well as Doug Purdy in the previous video, always talk about data being "dynamic and transparent" vs. code being "opaque and static"... what does that mean?

MS wants to get to a world where "software is data"... I wonder what the Lispers and generally, the dynamic languages guys will say about this. I also think this not quite the right focus. Models are about the "right" abstraction level... it doesn't really matter whether you interpret or generate... this depends on a number of non-functional requirements... Imagine running a data driven app (with an SQL server as a repository :-)) on an embedded device... I do agree that "data driven" is a good idea for many enterprisey apps, but it is not the right approach for all kinds of systems. Models - I think - *are* the right approach for all kinds of systems. It's just the question what you do with the code: interpret, or generate?

Hehe, the property form he shows on the canvas really does remind me of Naked Objects now :-)

The Quadrant stuff really does look very nice....

Now he shows a diagram right inside the workspace... Nice, but not overwhelming... Wow, now he nests the property view inside the tree. Nice -- but you'll run out of real estate quickly. I wonder whether they can also embed an editor for a textual DSL inside Quadrant, imaging some calculation rules as part of the data, you want to show them as text, with a nice editor, right inside Quadrant.

Looking at quadrant as he shows it, yes, it looks like an efficient way to interact with data. But I see now real consistent "language" yet. Maybe that's not the intent, but that's what I'd like to see.

Ok, becomes more interesting ... they now have a workflow diagram right inside the workspace. You can of course also author it directly in the workspace. Nice!

Question is, of course, if I want to build my own (graphical) languaga and want to integrate that into Quadrant, do I do this with "regular code", or with DSLs, too? (I guess, the latter, since they said previously that the tool itself id "data driven")

Florian mentions something quite interesting. And that is, that once *everything* is a model you can connect everything. For example, if implementation artifacts are models, and requirements ("goals") are also models, you can easily trace between these different things. Janos Stipanovits mentioned a similar potential for integration: software architecture and systems engineering.... very nice :-)

Ok, Don says it again .... Quadrant itself is Model-Driven. Nice!

Ok ... now they will show how "the data drives the tool" and how to customize it. Now it becomes interesting :-)

Flovo shows a diagram that is basically a "meta model" ... and ... he says they will integrate Intellipad into the Quadrant workspace. Cool!

He now shows the way how to customize the tool.... nice, completely reflective. And it updates in real time, no recompilation or redeployment. Everything is dynamic. Nice.

Sorry to repeat myself, but it's really a bit like "Naked Models" :-)

They repeatedly say "Smalltalk-like" ... interesting.

They use LINQ inside the tool to define queries from which to build diagrams and stuff.

Still seems quite simplistic how the define the diagrams via queries. But I guess this can be improved over time.

Ok, they prove that the tool itself is model-driven by changing the underlying models that describe the UI... and the UI changes. Really pretty much like Smalltalk :-) And the E4 guys could take a look, too!

cool -- they now show how the tool is built via the tool itself by changing some of the buttons by chaning model data.

Very nice - they were changing the data in the model that describes the ribbons, they used the usual table/form notation for that; then they changed the presentation, and they now have the ribbon display *in the editor*, directly in place. Cool :-)

This has to be the saddest bug I have ever seen. Unfortunately, I see this type of response all too often, where the user, despite having a perfectly readable stack trace, dump or error message, is expected to either a) prove to the developers that the problem still exists in the latest nightly build or b) provide a reproducible test case.

Running the latest nightly build may be trivial for client software, but for server software running on busy, production servers, this is impractical and difficult, if not impossible. Furthermore, in a production environment, reproducibility is not an easy feat, as conditions are never the same, and accurately reproducing the load of hundreds of users is far from scientific.

Need more examples of saddness? Here’s another one. It’s a MySQL bug about corruption on a storage engine. This one is particularly bad, as the developers keep insisting on trying to reproduce the problem with various versions, despite several users (myself included) confirming the problem across many versions.

Of course, Eclipse servers are affected by both of those bugs — Apache won’t gracefully restart because of the PHP bug under certain conditions and Bugzilla searches fail because of a storage engine issues.

But wait - it gets even sadder. Here is how the above PHP bug is closed (comment by the reporter) :

Whatever. If you do not want bug reports, I will not post any. I thoughtyou welcome help and want to improve the product but it seems you careonly about having less work. Forget it. Let this bug be.

IMHO, that a fair statement.

The MySQL bug is closed with this automated message:

No feedback was provided for this bug for over a month, so it isbeing suspended automatically. If you are able to provide theinformation that was originally requested, please do so and changethe status of the bug back to "Open".

I understand that the developers’ time is precious and that good bug reports are required, but users are not intimate with the source code, and often cannot easily provide more than a crash dump or an error message. That doesn’t mean there is not a problem with the code, so relying on the user to do all the heavy lifting seems quite unfair, and a great way to convince your users to not report bugs.

What?!  You’ve moved? Well just our blog.

We decided it was time to eat our own dog food so to speak.  With Denis having spent a lot of time recently upgrading our WordPress-mu installation and redoing the login procedure we thought it was high time that we started using our own hosting environment.  So here we are.  Denis imported all of our old posts and comments from Blogger but we’re leaving the old site up as some monument to our past, errr, ummm, glories.  We prefer to think of them that way, anyhow.

So anyway, this is our new blogging home.  See you around.

For those that are curious, Equinox is planning a move to Foundation 1.1 in the 3.5 timeframe... if you have any problems with this, speak now or forever hold your peace ;)

For those who don't like all this talk about tiny execution environments, check out BJ Hargrave's EclipseCon submission about OSGi Framework 2.0... J2SE-1.5 at the framework level... sounds fun!

The time has come finally for a release of the Groovy Eclipse plugin. The plugin has been published to the update site.

There are a few notes to make.

First off there is now refactoring support inside the plugin for your Groovy Code. To see this demonstrated head over to this wiki page. Besides documentation there are some pretty cool flash demos of the features which should entice.

Second, the groovy plugin now supports the 1.5.7 version of Groovy.

Third, this release does not contain support for the joint compilation of Java and Groovy code by the Groovy compiler. This is a priority for the next release, and is a perfect segue to the next note.

Fourth, please feel free to visit the wiki page Groovy Eclipse Roadmap. There the Groovy Eclipse team is collecting priorities and feedback for features to be added to future versions of Groovy Eclipse. The plan is to release another version here before the end of the year or soon after the new year, depending on the issues that are resolved, feedback from the community of users and the release schedule of new versions of Groovy.

Fifth, if you are having issues with the plugin, please contact either the Groovy Eclipse mailing list (you can subscribe here), follow Groovy Eclipse on Twitter. or browse/add JIRA issues here. Your feedback is much appreciated.

Finally, as the Groovy Eclipse project lead, I would like to thank our contributors that made this release possible, in particular Thorsten Kamann, Michael Klenk, and Heiko Bottger. Finally a shout out to Guillaume Laforge, for helping to keep Groovy Eclipse afloat and me on track. Thanks everyone!

Last Friday the submission system closed for new submissions. Fortunately. I had 53 submissions at closing time, all vying for a very limited number of slots. The fun task that befell me was to make that choice. Well, at least it looks like we will have a very strong program in March 2009!

If you want to see the submissions, you go the OSGi subissions page. Feel free to add comments or send me an offline mail about them. Any feedback is appreciated.

It is good to see the enthusiasm in the market for OSGi. Looking at all the submission at EclipseCon it looks like OSGi is hot!

Peter Kriens

The program committee's job is to create the best possible conference program and this means that we're not a passive group deciding yes or no - we're actively working with you, the authors, in our quest for the best EclipseCon content. One of the things we're finding over and over is that the abstracts as-submitted are not aimed at the correct audience.

The right audience for an abstract is the attendees and potential attendees: the program committee is a proxy for those people and we're evaluating your submission with our proxy role in mind. With your abstract, you are (in January and February) trying to convince the potential attendees to register and (in March) trying to convince the attendees that your talk is the best one of the seven competing parallel sessions.

Here's a nice short article relevant to writing abstracts: "An Easy Way to Create Learning Objectives" - when the program committee asks you to revise your abstract, start with that and remember: you're writing for the attendees.

Last week I was at the Eclipse Demo Camp in Berlin, my home town in Germany. This was my second demo camp so I was curious how it would compare to the one I visited early this year in Bern, Switzerland.


It turned out that they were quite similar. A lot of very interesting presentations coupled with a delicious buffet. Another similarity was the presenters' tendency to completely over-estimate their talking time. I remember that my talk at the EclipseCon 2008 also suffered from this a lot. I think I learned from it and I planned to talk only 15 of my 30 minutes and leave the rest for discussion.


My talk about the CDO Model Repository was the first one in a sequence of eight. Fortunately I managed to show my three architecture slides in 10 minutes, followed by a live demo of another 10 minutes. The rest of the time was dedicated to a lot of questions and answers. Very informative for me and the audience. Thank you!


After me Tom Ritter from the Fraunhofer Institut described their ModelBus effort. It reminded me slightly to what I saw in TopcaseD framework and indeed Tom talked about a former cooperation. I wonder if somebody would be interested in evaluating ways to integrate CDO with their ModelBus...


Then Volker Wegert from Siemens had a handicap while showing his SAP R/3 Connector for Eclipse RCP Applications: none of the attendees ever faced SAP back-ends. Nevertheless he managed to make it interesting!


Very interesting was Jens von Pilgrim's demo of GEF3D. I was amazed to see what they're able to do with 2D user interfaces! With a handful of code changes they turn an ordinary class diagram editor into a multi-layered 3D editor with connections between the layers and so much more. Amazing. And Jens is a collegue of my new CDO committer Stefan Winkler, so I guess I'll hear from him in the future.


Enrico Schnepel explained us how to use GenGMF to ease the development of GMF editors for large metamodels. I also always thought that the GMF's diagram configuration models are so flexible that they fail to easily support the 95 percent cases. Could be worth a look at GenGMF...


One of the talks was not on the agenda so unfortunately I can not remember the name of the student who showed a demo of his distributed shared model editing framework on top of EMF (or GMF?). In his talk he explained that he investigated CDO and found it inappropriate due to the lack of offline support. What a pity that he did not take the time to contact the CDO team. We are currently investigating ways to provide more disconnected modes of model sharing and it would have been so much nicer to co-operate rather than duplicate efforts! I'd appreciate very much his work in the CDO project and he agreed to consider this. Ed, didn't you mention recently how much you enjoy seeing our team grow and prosper? :P


Theofanis Vassiliou-Gioles demonstrated their TTworkbench - an extensible Eclipse based test environment - in a very detailed way. I felt like a trainee...


Stephan Herrmann from the TU Berlin gave the last talk: Plugin reuse and adaptation with Object Teams: Don't settle for a compromise! It looked a bit like an alternative approach to AspectJ and his examples were nearly as amazing as the ones at the ESE talk about Equinox Aspects. I must admit that I'm a bit scared about the security implications about such major changes to published and deployed code, un-anticipated by their providers. But it's clear that many things can be achieved with it that were impossible without.


The demo camp started at 6 p.m. and now it was already far past 10. Only two short breaks so most of us looked a bit tired already and I also decided to go home. For future demo camps I would really limit the presentation time to 15 minutes per talk and allow for discussion afterwards. It should be clear that a demo camp is not a training where we should learn the last detail of a tool or technology. It should create interest and the wish to dig deeper back at home.