Xtext, DSLs, MDSD, Eclipse

In my current project, I need to launch an external application and maybe execute some additional commands on this external application. Due to the very nature of the project, the whole system will always be run on Mac OS X. So I thought, "why not use AppleScript"?

Turns out using AppleScript to launch applications is fairly easy, all you have to do is

tell application "name of your app" to launch

If you want to try this from the command line, osascript comes in handy:

osascript -e 'tell app "iTunes" to launch'

So far so good. Should be easy to do this from Java, shouldn't it? Turns out it's not so easy at all. Let's try this:

  String launchCmd = "osascript -e 'tell application \"iTunes\" to play'";
  process = Runtime.getRuntime().exec(launchCmd);

  BufferedReader bufferedReader = new BufferedReader(
    new InputStreamReader(process.getErrorStream()));
  while ((lsString = bufferedReader.readLine()) != null) {
    System.out.println(lsString);
  }

I'm not sure why, but it results in a nasty "0:1: syntax error: A unknown token can't go here. (-2740)" error message.

But there is another signature for Runtime.exec:

  String[] cmd = { "osascript", "-e",	"tell app \"iPhone Simulator\" to launch" };
  process = Runtime.getRuntime().exec(cmd);

  BufferedReader bufferedReader = new BufferedReader(
    new InputStreamReader(process.getErrorStream()));
  while ((lsString = bufferedReader.readLine()) != null) {
    System.out.println(lsString);
  }

... and this works out just fine!

Thanks for reading this post. You should follow me on twitter here

The Eclipse DemoCamp in Hamburg was a huge success - more than 110 people signed up and most of them actually showed up at the event:

The program was packed with interesting talks and we were lucky to be able to present some very well known speakers:

1. Tom Schindl: E4 - A short overview
2. Jan Köhnlein: Combining graphics and text in model editors
3. Jochen Krause: RAP
4. Nils Hartmann, Gerd Wütherich: Fifty ways to build your bundle...
5. ekke (Ekkehard Gentz):redView - dynamic views for business applications

If you were not lucky enough to attend the DemoCamp, here is a short summary of the sessions:

e4 - modeling meets runtime (Jochen Krause on behalf of Tom Schindl)

Tom Schindl couldn't attend the DemoCamp due to heavy snow in Innsbruck (the airport was short of planes to fly out, actually). After a short vcon with Tom, Jochen Krause held the e4 demo on Tom's behalf.

e4 has three principal aims:

1. simplifying the Eclipse programming model
2. enabling the platform for use on emerging web-based runtime technologies
3. and broadening participation in development of the platform

One of the measures to make programming Eclipse easier is to define a list of core services and make sure they have a really decent API. This list of services is called "The 20 Things" (see the Eclipse wiki for more information).

You might have heard that EMF is playing an important role in e4 and I think it is one of the most amazing things about e4 that the entire workbench is modeled, of course using EMF. Actually, you can change the workbench at runtime by just modifying the underlying model at runtime. I think it is very exciting to see modeling and runtime technologies converge in this project.

e4 also makes massive use of dependency injection, which allows for a flat object model (Instead of providing a subclass for every special feature, you can just inject other classes providing that particular feature). We had a discussion about dependency injection. Jochen showed that several methods in e4 use String-based dependency injection, which of course leads to several problems. Sven pointed out that this is not a DI problem per se and suggested to use interfaces to alleviate the situation.

Heiko raised the question of whether we should have a dedicated session on dependency injection at one of the next democamps:

Jochen continued his session, explaining how the e4 UI is being rendered by a presentation engine which can be configured using various renderers, each one providing an individual look and feel.

e4 is the future of Eclipse, and Jochen concluded his talk by pointing out that in order to ensure e4 has a sustainable future, companies and individuals should participate in the development of e4. This can be done by:

• Playing around with e4 and providing feedback
• Participating in the development process (see the e4 project homepage for more info)
• Paying existing committers (see Tom's blog posting to learn how to buy one and get one free)

More info on e4 can be found on the Eclipse wiki.

After the talk, we had a short break to set up the next presenter, enjoy some refreshments and, of course, socialize:

Combining graphics and text in model editors (Jan Köhnlein)

After the break, Jan Köhnlein took stage and told the audience that graphics and text and no different, but really are just two views on the same thing:

Jan pointed out that both text and graphics have their relative virtues:

Text...

• provides a detailed view on things
• can have a very formal syntax
• can be typed using standard text editors
• can be managed using standard versioning mechanisms (merge / diff)
• can be typed fast

Graphical representations on the other hand...

• provides high-level views and a good overview
• suggests non-formalism
• requires custom editors for your graphical notation (i.e., you need to write them)
• has no good support for merging / diffing
• requires the user to use a mouse a lot, and thus is slower than a text editor

Apparently, both have advantages, so why not use both?

In the following 5 minutes, Jan gave an ultra-quick introduction in how Xtext (as a representative of a textual modeling toolkit) and GMF (as a representative for a graphical modeling toolkit) work. The bottom line is both use Ecore metamodels, so we should be able to combine both.

It turns out, however, that Xtext and GMF metamodels are slightly different and you need to take some precautious steps in order to make them interoperable.

After this excursion into the theory behind the convergence of graphical and textual editors, Jan showed two editors, one graphical and one textual that synced live. Changing the model in one editor and saving it effected an immediate update in the other editor - really neat.

Jan pointed out that this is all very fine, but sometimes you really want to have a tight integration. As a proof of concept, he showed a GMF-based editor with an embedded Xtext editor: as soon as he pressed F2 to edit a field in the graphical editor, an inline Xtext editor would pop up, featuring syntax highlighting, code completion and error markers - really awesome!

More information on Xtext and GMF can be found on their respective homepages. Jan works for itemis and provides consulting and training for these technologies.

All these exciting things must have made people gasp for air, because the oxygen level in the room was very low at the end of the session, so we had another break. As always with gathering like this, hallway talks very equally important as the sessions, and people made good use of the break:

RAP (Jochen Krause)

Jochen's presented his talk on RAP without a single slide - "in the tradition of the Karlsruhe DemoCamps", as he pointed out.

No technical session without some history and some theory, so Jochen first explained that RAP implements the Half Object Pattern and demoed the very first version of RAP. While running an Eclipse UI in the browser is all very exciting, feedback from initial users wasn't too positive: "please spare us this look'n'feel in the browser!"

So the good people at innoopract (now EclipseSource) spent some time to implement custom styling for RAP UIs, which Jochen showed in his second demo, which he called "The Enterprise Look'n'Feel" due to it's feasibility for enterprise applications.

The third demo featured "rounded corners" (see RAP New & Noteworthy). While this might seem like little gained, Jochen explained that implementing rounded corners was both important on an acceptance level and challenging on the implementation level. Would you have thought that rounded corners are implemented using CSS on FireFox and VML on Internet Explorer?

Of course, RAP is implemented as an Open Source project at Eclipse, welcoming any contribution from users worldwide. Jochen demonstrated how great the Open Source model works by showing off a ribbon-style command bar for RAP which is available on Google Code (see the rapit project home page)

In the next demo, Jochen showed how he integrated EMF and RAP. His goal was to RAPify the EMF tree editor for EMF models. It turned out that basically it is very simple to convert the EMF editor (or any other Eclipse plug-in for that matter) into a RAP application - only very little adjustments were needed. However, as web applications are multi-user applications by definition, additional care has to be taken when converting editors. As Eclipse is a single-user application, editors are not prepared to be executed in a multi-user environment. Jochen explained how he tried to use CDO to store the edited models on a remote server, but failed due to the complexities of CDO. He succeeded by using CouchDB, a database written in Erlang and with an HTTP interface (look ma - no JDBC driver needed!).

Jochen concluded his session with a few notes on features they've just completed (Drag'n'Drop) or which are not available (yet) like GC.paint.

After that, he took some of the audience's questions, e.g. "How many users can a RAP server take?". Of course, it depends, but you can roughly count 1MB per user and workbench.

Jochen thought it would be OK to continue without a break, but Martin decided we should rather have a short break to let in some air.

More information on RAP can be found on the Eclipse wiki and on the project homepage. Jochen's company EclipseSource provides professional services, training and resources around RAP, so have a look at their website.

50 ways to build your bundle (Gerd Wütherich & Nils Hartmann)

After the "short" break, Gerd Wütherich and Nils Hartmann presented their view on build management: "Fifty Ways to Buid Your Bundle":

Facing the fact that nobody seems to be too excited about build management these days, they decided to arrest people's attention by adapting the well-known story "A Christmas Carol" by Charles Dickens. A brilliant idea, which really made people laugh at various points throughout the presentation.

The presentation was subdivided in three parts:

The Ghost of Build Past
Gerd and Nils explained how in the past, people have been building bundes using PDE build, using a Manifest-First-approach. Building bundles with PDE build is rather cumbersome: you have to setup map files in order to help PDE build to derive ANT build files which will then be executed by the AntRunner inside Eclipse. While this ensures the build process sees exactly what Eclipse sees when you develop your bundles in the workspace, this basically makes debugging your build process very complicated.

The Ghost of Build Today
Today, we've got bundles everywhere and OSGi is being used not only for Eclipse plug-ins, but also for conventional applications. As good programers obeying the DRY principle, we want to have a redundancy-free description of our build artifacts, i.e. derive build dependencies by looking at MANIFEST.MF. In the enterprise, things can get really nasty, as we often need to integrate various very different build systems: you might have to build an EJB client JAR (maybe using Maven) which then need to be integrated in an Eclipse RCP client application, which again needs to be built using PDE build.

Nils and Gerd showed a slide which listed all major build tools for bundles, among them:

• Springsource Tool Suite
• PDE
• Athena
• PluginBuilder
• Buckminster
• Tycho
• Maven
• b3
• Ant4Eclipse
• PDE build
• bnd
• Ivy
• Buildr
• IDEA
• Sigil
• buildr4osgi
• OsgiPlugin
• ANT
• Bundlr

After which they showed three exemplary setups how to actually build bundles:

1. ANT4Eclipse
2. Maven Tycho
3. Buckminster

Please refer to their slide deck, slides 14 - 16 for detailed diagrams on these three setups:

Ghost of Build Future
As things get more complicated, build management will also most likely become more complicated. Gerd and Nils pointed out that build management might be an unthankful job, but it must not be assigned to "people that aren't good at programming". Instead, they advocated making build management a first class citizen in computer sciences education.

More information on the tools and techniques presented are available at their respective home pages. In addition, you can contact Nils and Gerd and bug them with your questions. They're consultants, so they can be hired.

redView - dynamic views for business applications

The final session was held by Ekkehard Gentz, better known as ekke. He showed a smart combination of Eclipse technologies: Riena, EMF, openArchitectureWare (Xpand, Xtend, MWE) and Xtext. Of course, being an Open Source advocate, Ekke and his team mate Florian provide this stack as an Open Source project on Google Code.

redView is a declarative framework based on the Eclipse Modeling Framework (EMF), for creating RCP Views enriched with Riena Ridgets. It uses EMF to describe the application with a model. An Xpand-based code generator will then transform the model into code for the application. Ekke states that their goal is not to limit developers' creativity, but instead relieve them from the burden of having to write all the boilerplate code.

redView supports the most important UI elements, including some Nebula widgets. One thing I fond very impressive was their UI editor. Ekke gave a demo in which he hosted the UI model on a CDO (which seems to be Eclipse's wunderkind) server on a virtual machine. He started a second virtual machine, running an instance of the application. Upon changing the UI model in the UI designer on one machine, the UI was updated immediately on the second machine. Ekke pointed out that this usage pattern is especially useful in prototyping scenarios: the developer changes the model on his PC in his office and the customer can immediately see the changes on his machine, hundreds of kilometers away.

More information on redView can be obtained from their project homepage. Ekkehard is a freelance consultant, so you can hire him if you've got any questions regarding the technologies presented.

Gimmicks

After the demos, we raffled off 20 Eclipse Keybinding Mugs (see Kim Moir's blog post for a 360° shot of the mug) - congratulations to all winners! it-agile also provided a fine selection of agile swag: retrospective mugs, team calendars, post-its and what have you:

Despite the fact Ralph Müller couldn't attend the event, we eventually headed to the EAST bar for some frosty beverages.

All in all, it has been a very enjoyable event and from what I gathered, most attendees seem to have enjoyed the DemoCamp as well.

Thanks everyone for attending! Also, thank you to all speakers. Last but not least a big thank you to Natalia for taking pictures of the event!

Hope to see you again at the next DemoCamp in Summer 2010!

Thanks for reading this post. You should follow me on twitter here