Jan's Blog

Impressions on GEF

2012-01-18T19:30:00.005+01:00

For the Generic Graphical View project I've been digging deep into the Graphical Editing Framework (GEF) lately. GEF is the base technology below almost any graphical framework in the Eclipse environment. I wanted to keep the tool stack as low as possible and have the maximum control on everything so I decided to use GEF directly. Here are my impressions.

I really like GEF's base architecture: The separation between Draw2D and GEF, the concepts of Tools, Requests, EditParts and EditPolicies. It helps you to find the component to change in order to implement a new feature quickly. The pictures in the GEF online help really help
understanding this.

Pecularities

In some areas GEF appears to be kind of rusty. A whole bunch of relevant commercial products has been relying on it for years. Long term backward API compatibility has taken its toll. Some things definitely need a serious overhaul and often a better naming. I am very happy to hear that a 3.0 version is planned. Here is my wishlist for improvements:

Make coordinates double by default. Integer coordinates often result in rendering glitches due to rounding errors and are not well suited for scaling.
Add alpha channel (transparency) support.
Revise scaling of fonts: Sometimes a label's bounds don't match its text's extend.
Rename methods of the update mechanism. I am often confused about the semantics validate(), invalidate(), invalidateTree() or revalidate().
Rectangular bounds are not well suited for round things like ellipses. Similar to that, clipping child figures only makes sense for Viewports but nothing else. The need of an invisible container figure for side affixed children is really an ugly workaround.
Diagram layout does not take connection labels into account.
Add support for curve connections.
The feedback figures - the surrogates when a figure is moved or resized - seem to come from a time where hardware graphics acceleration was pure luxury. If you have nested edit parts you might have to reimplement the nested figure construction twice for nicer feedback.
Using a bit less inheritance and more composition would be fine.

Mutable Geometric Primitives

As many other graphics frameworks, GEF code tries to create as little new objects as possible. Geometrical primitives such as points, dimensions and rectangles are therefore mutable and reused often. There are even things as a static Rectangle.SINGLETON for temporary calculation. This pretty much reminds me of good old C++. I am not sure whether such optimization is still necessary. It results in pretty unreadable code:

Point p = figure.getLocation(); 
// p is the location in local coordinates
p.getParent().transformToParent(p);
// now p is in parent coordinates
Point q = p.add(p).scale(2):
// this will also modify p

You see: As the semantics of the variable changes, it is no surprise you cannot find a more expressive name than p. In addition, you have to be very careful if you are dealing with a reference or a copy. Modifying a Translatable (once again bad name, as Dimension also implements this interface) directly can also circumvent an event mechanism. This is really error prone. I'd strongly advise to introduce immutable primitives.

Coordinate Transformations

The way transformation between local, global and parent coordinates are handled is somehow unsuggestive. I've used various 2D and 3D scenegraph-based frameworks but I never got as confused with coordinates as in GEF. For example, if you have a ScalableLayeredPane showing some scaled content, its translateToAbsolute(Point) method will not take the scaling into account while translateToParent(Point) will.

Some Hints

Starting with GEF from zero is hard. You will likely spend a serious amount of time debugging why your diagram doesn't show anything at all. Better copy some basic setup from one of the GEF examples. Here are my favorite pitfalls:

missing minimum size on figure - figure does not show up at all in some layouts
wrong coordinate system - figures don't appear where they should, somtimes in nirvana
wrong layout manager, e.g. a plain XYLayout on a FreeformFigure - results in endless layout loop
reusing a geometry element instead of making a copy - completely unpredictable editor behavior
the default ChangeBoundsRequest does not take local coordinate systems into account

For better diagram layout algorithms the KIELER project offers a good choice.

Multitouch Gestures in the Generic Graph View

2012-01-18T17:19:00.005+01:00

In my previous post, I've already described the discovery mechanisms of the Generic Graphical View project: Starting from one node you can step by step reveal other connected nodes in the same model. The model itself is fixed - it is still a view! - but the user can decide herself which subset of elements should appear in the diagram. That behavor allows to create diagram views focussed on a specific semantic aspect of the model.

The challenge is to find a decent UI for nodes wich have several hidden connections. How should a user select any subset of these?

Since the Helios release SWT supports four multitouch gestures: PAN, ZOOM, SWIPE and ROTATE. On my Mac's touchpad these gestures are actually easier to perform than a conventional drag operation because there is no extra mouse button. So I decided to give it a try and have a look how gestures could be used in the graph view. Here is a screencast showing the results:

SWT's multitouch API is fairly simple (example snippet). The first step was to add multitouch events to GEF, such that the can be handled in the same way as mouse or keyboard events. I had to extend a couple of GEF classes. If you're interested in the details, have a look at the classes in the package org.eclipse.xtext.graphview.behavior.gestures and the GraphViewRootEditPart.

These changes allow to use a ZOOM gesture on a ScalableFreeformRootEditPart.
Note that the PAN gesture is already supported by GEF because the FigureCanvas uses hardware scrolling. Unfortunately, these event is always consumed, such that it will not make it through to other GEF elements.

The ZOOM gesture can also be used to drill down into elements. If the mapping defines an open reference to another diagram, you can drill down by selecting it and performing the ZOOM in gesture. If you‘re inside a drill down diagram, you can ZOOM out into the container diagram.

Any Tool can now handle multitouch gestures by implementing the IViewerGestureHandler interface. For a DragTracker this makes no sense, as it is exited as soon as the mouse key is released and you cannot start a drag and a multitouch gesture simultaneously.

The RevealGestureTool works as follows: Click on the + button to reveal the hidden connected elements, Then use ROTATE or SWIPE to rotate elements, ZOOM to change the distance and right-click to select and pin individual elements. Another click will commit the input.

Discovery Diagrams for the Generic Graphical View

2012-01-18T15:16:00.005+01:00

If you've read my previous posts or seen my presentation at EclipseCon Europe 2011, you'll already know the Generic Graphical View framework: Using two Xtext-based DSLs - one for mapping semantic to graphical elements and the other for styling the figures - you can easily create nice looking diagrams for any Java based model.

 In its first version the contents of the diagram was entirely defined in the mapping DSL. It was only possible to restrict the visible elements to a subset of the model by adding filtering expressions in the mapping. For bigger models it was hard to focus on a subset that is not structural defined but based on semantics, e.g. all classes that deal with addresses in a CRM application.

Many graphical frameworks handle the selection of the visible elements in a diagram by means of dialogs. The user is then forced to switch between keyboard and mouse which is annoying, and these dialogs are often complicated and unintuitive. The goal for the Generic Graph View project was to build a UI for choosing the diagram contents that uses the mouse or trackpad only and avoid dialogs at all cost. The following screencast demonstrates the basic functionality.

As a first step, actions were introduced that allow to hide existing graphical elements - nodes, labels or connections. If you hover over an element, you'll get an popup button allowing to remove it from the view. So you can start with a big diagram and strip it down to what you want to see. Once an element inside a node has been removed, you can restore the node completely using another popup button. You can define elements as initially hidden using a hidden flag in the mapping definition.

In addition to the subtractive approach, you can step by step extend the diagram contents from an initial node. If you're hovering over a node that has hidden connection, several + buttons will popup. When one of these buttons is triggered, the hidden elements and connections will appear in transparent arranged in a circle around the source element. In the same drag operation you can change the distance and the angle of that circle. This behavior will get really cool with multitouch gestures, which I will cover in a separate post.

Eclipse Con Europe 2011

2011-11-07T09:54:00.006+01:00

The slides of my talk A Fresh Look at Graphical Editing at Eclipse Con Europe 2011 are online now. If you're interested in the code it's on github, but remember it's a prototype - no tests so far, no support. Unfortunately, there was no cake being served at 5pm, so the pie fight had to be cancelled.

As I have been asked this a couple of times at the booth: I am convined it makes no sense turning the presented view framework into a graphical editing framework. I am not entirely opposed to graphical editors but keep in mind that

You're going to need much more than graphical editing frameworks provide (projection, navigation, browsing, ...) I'd estimate a factor of 10-20 in the effort of building a graphical tool as opposed to a textual tool.
The bi-directional mapping from the semantic model to the graphical one is source of a lot of problems. Not all of them can be hidden from the users.
The structure of the semantic model must match the diagram model. This is not even true for the simplest models like UML2 class diagrams. You should be in a position to change the semantic metamodel to have a perfect structural match.

Would have been interested to discuss the last point with Bran Selic, who claimed in his keynote that UML2 is cool but the tools suck...

Eclipse Con Europe 2011 was an excellent event as always. I really enjoyed meeting all the nice people from the community. Thanks a lot for the organization and especially for the delicious food.

But remember: After the conference is before the conference. The CfP for Eclipse Con 2012 in Reston, Virgina, is open. Hope to see all of you there.

Join My Pie Fight Session at EclipseCon Europe 2011

2011-10-31T10:31:00.006+01:00

Competition is hard at EclipseCon: Everybody has to make sure to get the most participants into his talk. As Sven already announced a quiz for the same timeslot as mine I've had to figure out something even more exciting.

So here's my idea for my session:

I'll begin the session ranting on every Eclipse project that's somehow related to graphics. I'll shamelessly reveal all of their weaknesses. Everybody involved in one of these projects will be so offended that they start to get personal, first against me then against each other. When emotions boil up, I expect people to self-organize in teams, like The Knights of GMF Runtime or The Zest'o'Maniacs. My session is at 5pm so I expect a good supply of cake as in the years before. I am starting the fight by throwing the first cake, e.g. on the GMF Tooling Ultras. They try to answer but unluckily hit a member of the Spray Front, who's already in the midst of a quarrel with a Graphiti Warrior. Thinking it was a GEF Cyclope who threw the cake... A real pie fight breaks loose.

Hehehe (demonic laughter)

Well... thinking again... the cake at EclipseCon is usually quite yummy. It would be a pity to waste it in such a way. Maybe I should come up with something more peaceful.

OK, I see, I have to make that differently: I am going to point to some general issues with graphical editing. I'll weigh the cost against the usefullness and show, why an interpreted graphical view is so much simpler to implement and to use than a graphical editor. Second part will be a live demo of a prototype for such a framework.

Maybe I should bring a helmet, just in case someone did not notice my change of plan.

Git and Bugzilla patches

2011-09-13T11:21:00.007+02:00

I am one of these unteachable conservatives that sometimes prefer the shell over IDE. Using git is not an exception here. One of the things I've always been missing was to apply a patch that is attached to a bugzilla entry directly, i.e. by referring to its URL without downloading it to a file. Fiddling arround a bit, I found a solution that I think is elegant.

You'll need wget for this to work. On my Mac I use the one from Mac Ports.

Add the following line to your .profile (or the config file of whatever shell you use)

git config --global alias.applyurl '!wget -qO- $1 | git apply -'

You should now have a new git command applyurl. Now open the bug with the patch you want to apply in your browser and copy the link of the patch. Finally you can on the command line, you can type

git applyurl [paste the url here]

That's it.

Extending Xbase

2011-07-14T20:13:00.005+02:00

The new expression language library Xbase allows to integrate expressions in your own Xtext 2.0 DSLs. Xbase offers a grammar, a large runtime library and a compiler as well as an interpreter to execute these expressions. Thus, Xbase opens the field for a much wider class of DSLs and annihilates prior advantages of internal DSLs over external DSLs based on Xtext.

In a series of internal workshops on Xbase, I've often encountered one question: Can we extend the expressions of Xbase? In this blogpost, I am going to show you how to do that. It is based on the domain model example shipped with Xtext 2.0, which you can instantiate by choosing File > New > Example... > Xtext > Xtext Domain-Model Example.

The Grammar

By default, Xbase only knows integer literals. In this example we are adding decimal literals.

If you want to add a new concept to Xbase expressions syntactically, you have to hook into the right rule of Xbase. As the name suggests a literal can be added in the Xbase rule XLiteral. So in the Dominamodel.xtext you have to add


import "http://www.eclipse.org/xtext/xbase/Xbase"
...
XLiteral returns XExpression:
  XClosure |
  XBooleanLiteral |
  XIntLiteral |
  XNullLiteral |
  XStringLiteral |
  XTypeLiteral |
  DecimalLiteral; // our new alternative

DecimalLiteral:
  intPart=INT '.' decimalPart=INT;

As the EPackage of the domainmodel language is generated this will introduce a new EClass DecimalLiteral as soon as you regenerate the language infrastructure.

Type Provider

For the sake of simplicity, our decimal literal will be mapped to java.lang.Double. We have to adapt the type provider accordingly


public DomainmodelTypeProvider {
  @Inject
  private TypeReferences typeReferences;  
  ...
  protected JvmTypeReference _type(DecimalLiteral literal, 
                                   boolean rawType) {
    return typeReferences.getTypeForName(Double.class, 
                                         literal);
  }
}

Compiler

The compiler has to understand what to do with decimal literals. We have to add a method that appends the concrete syntax of the Java double literal for a DecimalLiteral


public class DomainmodelCompiler {
  ...  
  protected void _toJavaExpression(DecimalLiteral expr,
                                   IAppendable b) {
    b.append(expr.getIntPart() + "." 
      + expr.getDecimalPart());
  }

  protected void _toJavaStatement(DecimalLiteral expr, 
                                  IAppendable b, 
                                  boolean isReferenced) {
    generateComment(expr, b, isReferenced);
  }
}

We can now use decimal literals in your expressions and they are correctly converted to java.lang.Doubles. The following domain model should now compile:


entity DecimalLiteralTest {
  op approxPi() : double {
    3.1415926535
  }
}

Note that autoboxing/unboxing works in Xbase the same as in Java. Still we do not have any operations for decimal literals. The next section shows how to add them.

Operators

Operators in Xbase are implemented as Java methods following a naming convention. For example, the operator + will be mapped to a call to a method named operator_plus(). There are several places where Xbase tries to find this method

in the current type as operator_plus(OperandType1, OperandType2)

in the class of the first operand, as OperandType1.operator_plus(OperandType2)

in the extension scope as operator_plus(OperandType1, OperandType2)

The first alternative is ruled out, as we want to provide global operations. The second does not apply as we cannot change the final class java.lang.Double, so we're eventually dealing with alternative 3.

Let's write a new extension library class holding the operations as static methods. These methods need to be available at runtime, too, as the generated Java code will call them. That's why it is a good idea to put such extension classes into a separate plug-in org.eclipse.xtext.example.domainmodel.lib.


package org.eclipse.xtext.example.domainmodel.lib;
public class DecimalExtensions {
  public static Double operator_plus(Double x, 
                                     Double y) {
    return x + y;
  }
  public static Double operator_minus(Double x, 
                                      Double y) {
    return x - y;
  }
  public static Double operator_multiply(Double x, 
                                         Double y) {
    return x * y;
  }
  public static Double operator_divide(Double x,
                                       Double y) {
    return x / y;
  }
}

Globally available extension classes and literal classes have to be registered in the
StaticMethodsFeatureForTypeProvider. We override it


package org.eclipse.xtext.example.domainmodel.scoping;
...
public class DomainmodelStaticMethodsProvider 
    extends StaticMethodsFeatureForTypeProvider {
  @Override
  protected Iterable getVisibleTypesContainingStaticMethods
    (JvmTypeReference reference) {
    Iterable resultFromSuper = 
      super.getVisibleTypesContainingStaticMethods
        (reference);
    if (reference != null && reference.getType() != null
        && "java.lang.Double"
          .equals(reference.getType().getIdentifier())) {
      return Iterables.concat(Collections.singletonList
("org.eclipse.xtext.example.domainmodel.lib.DecimalExtensions"),
          resultFromSuper);
    }
    return resultFromSuper;
  } 
}

and bind our customized implementation


public class DomainmodelRuntimeModule 
  extends AbstractDomainmodelRuntimeModule {
...
  public Class 
      bindStaticMethodsFeatureForTypeProvider() {
    return DomainmodelStaticMethodsProvider.class;
  }
}

If you add the plug-in org.eclipse.xtext.example.domainmodel.lib to the classpath of the project in the runtime workspace, the following domain model should compile:


entity DecimalLiteralTest2 {
  op circleArea(double radius) : double {
    3.1415926535 * radius * radius
  }
}

Graphical Syntax View for Xtext

2011-07-08T12:42:00.003+02:00

I demoed it so often that I almost forgot blogging about it: In Xtext 2.0 you can now visualize the syntax of your DSLs grammar in a live railroad diagram view. The view supports navigation between the editor and the view and you can export your diagrams to a file. We even have a special representation for unordered groups. Watch this screencast to see it in action:

The syntax graph is implemented in plain Draw2d using a custom layout algorithm. It is technically not related to the generic graphical view I presented in my previous blogpost.

Using Xbase to Define a Generic Graphical View

2011-06-24T14:28:00.004+02:00

While textual representations such as code are perfectly suited to process the details of an object model, a graphical view can be very helpful to display the relationships between objects.

Most graphics frameworks in the Eclipse ecosystem provide graphical editors. Usually, the semantic model is mapped to its graphical representation using a hard wired transformation, be it in code (GEF, Graphiti) or in models and a code generator (GMF, the upcoming Spray project). There are two issues here: First, as opposed to a graphical view, a graphical editor requires the mapping to be bidirectional. That constrains the transformation a lot, e.g. requires having the same structure on the graphical as on the semantic side. Second, hard wiring the mapping introduces extra compilation/generation/deployment turnarounds.

I've created a prototype of a graphical view that is configured using two textual DSLs: A mapping DSL that declaratively describes the transformation from semantic objects to graphical elements, and a styling DSL to modify the graphical representation. The graphical view interprets the mapping and the stylesheet on a given input model, giving immediate feedback on changes of these live models.

Both DSLs are implemented in Xtext 2.0 and make heavy use of the new Xbase expression language library. As Xbase uses Java's typesystem, we can refer to any POJO as an input model. Xbase's rich semantics allow comfortably navigating the models references, and its interpreter can be customized easily to fit our needs. The graphics are implemented using plain GEF and Zest layouts.

The following screencast gives you a short demo. (Sorry for the poor video quality, it gets better if you got to full screen mode)

Rename Refactoring in Xtext 2.0

2011-06-06T10:22:00.003+02:00

The upcoming Eclipse Indigo version of Xtext ships with experimental support for generic rename refactoring. It allows you to rename model elements and automatically fix all links to these elements. This blog entry describes the main components behind this new feature. The following screencast shows refactoring for a domainmodel language:

Enabling Refactoring

To enable refactoring support for your language, you have to add the RefactorElementNameFragment in the fragment section of the MWE workflow of your language, e.g.


// rename refactoring
fragment = refactoring.RefactorElementNameFragment {}

The fragment has an additional flag useJdtRefactoring which can be used to delegate to JDT's refactorings for languages using the JVM types compiling to Java (i.e. the domain model example or Xtend). Usually users are fine with the defaults.

After running the workflow, you will have working refactoring support - at least if you have stuck to the defaults with regard to naming, cross-referencing. and indexing. Give it a try. If it doesn't work yet you have to adapt the infrastructure a bit more.

Customizing

The most likely component you want to customize is the IRenameStrategy. This component defines how the declaration of the target element is performed. It has two major responsibilities:

Apply and revert the declaration change on the semantic model (methods applyDeclarationChange and revertDeclarationChange))

The default is to look for an EAttribute 'name' on the target object and set its value using EMFs reflective API.

Create the LTK Change objects of the declaration change. These changes will be aggregated, checked for overlaps, presented to you in the preview and finally executed if you apply the refactoring.

The default is to use the ILocationInFileProvider to locate the text range representing the name and create a ReplaceEdit for it.

As the IRenameStrategy is a stateful object, you have to bind a custom IRenameStrategy.Factory instead of the strategy itself to integrate your changes.

The other component you might want to customize is the IDependentElementsCalculator. Dependent elements are those elements whose qualified name changes when the target element is renamed. E.g. when you rename a Java class the qualified names of its inner classes change, too, thus references to these have to be updated. This calculation is performed by the IDependentElementsCalculator. By default, all elements contained in the target element are added. This matches Xtext's default strategy of qualified name computation.

The Internals

The following describe the steps taken in the refactoring and the responsible components

Refactoring UI

In terms of UI, the refactoring of Xtext looks pretty much the same as in JDT. When the user has triggered the refactoring - by a keystroke or using a context menu entry - the editor goes into a linked editing mode allowing to edit all occurrences of the element in the current document at once. Pressing the keys again or using the popup menu, the user switched to a dialog wizard or a preview wizard. Thanks a lot to Holger who did the major work on the UI.

The UI parts pass an element of type IRenameElementContext to the non-UI components, holding information on the target element, its EClass, the current editor etc.

Non-UI

The non-UI part and thereby the actual refactoring is mainly managed by the RenameElementProcessor.

As a first step, it loads the model declaring the element to be renamed into a new ResourceSet that is configured with respect to the declaring language. This allows to easily abandon all changes as well as avoiding concurrency issues. Some basic checks are performed like 'is the element available' or 'is the resource writeable' and the IRenameStrategy is initialized.

Then we calculate the dependent elements.

After that the URIs of the elements that are affected by the refactoring are calculated. Those URIs may change, e.g. if you use a name-based fragment strategy. So we calculate the original URIs, apply the change and recalculate the new URIs. The result is a Map<URI, URI>. This task is the responsibility of the IRenamedElementTracker.
In the end, the changes are reverted to leave the resource in the same state as before.

The final step is to handle the cross-references to the renamed elements. We have to consider resource internal cross-references as well as the ones from other resources. The latter can be retrieved from Xtext's index. Note that if your external cross-references are not indexed, they won't be found and consequently won't be updated by the refactoring.

As references can come from any other language, we use a ReferenceUpdaterDispatcher that searches for local and indexed references and dispatches to the IReferenceUpdater of the referring language. We have two implementations of this interface: The DefaultReferenceUpdater works with Xtext resources and uses the language's serializer to update the reference text. OTOH, the EmfResourceReferenceUpdater works for all EMF based languages and re-serializes the whole resource after applying the semantic change.

Rename Participants

Finally, one refactoring can trigger another. E.g. when renaming a rule in an Xtext grammar, the returned EClass should be renamed, too. For these cases, you can register a RenameParticipant by the common means of LTK. If the target of the participant is Xtext based, you can use a AbstractProcessorBasedRenameParticipant in order to reuse lots of the already described classes.

EclipseCon 2011 Slides

2011-04-06T15:12:00.001+02:00

EclipseCon 2011 was once again a cool conference, even though I really needed a week of holiday to recover from the bad weather, the jet-lag and the general lack of sleep :-) This is why it took me some time to upload the slides of our presentations. But better late than never, here they are.

First, Sebastian and me presented What's Cooking in Xtext 2.0. The room was almost full, and when I asked a vast majority of the audience had already had contact with Xtext. To me that shows that Xtext has really become mainstream, a really good feeling. Here are the slides:

What's Cooking in Xtext 2.0

On Thursday, Sven, Sebastian and me gave the tutorial on Pragmatic DSL Design with Xtext. There were so many participants, that we had to switch rooms with Stephan Herrmann's tutorial on Object Teams. Thanks for that, Stephan! And here are our slides:

Pragmatic DSL Design with Xtext, Xbase and Xtend 2

Did I mention EclipseCon?

2011-03-11T16:14:00.003+01:00

I just realized that I haven't blogged on this year's EclipseCon yet. Time to do that. You might have guessed it:

As a committer to several Eclipse projects, I am really looking forward to meeting "the family". It's always been big fun and I guess it will be the same this year. But the main reason for going there is of course:

Together with Sebastian I will give a talk on What's cooking in Xtext 2.0 on Tuesday at 2pm. We're eager to show you all the new features of Xtext we've been working on during the last months, especially the expression language library Xbase and the code generation langauge Xtend.

You should not miss our tutorial
Pragmatic DSL Design with Xtext, Xbase and Xtend 2 on Thursday at 10:30am. Sven will join us to give you a walk through tutorial on a modern way of creating DSLs. We just had another rehearsal on this one and I promise you it will be a real burner.

All of that wouldn't have been possible without the support from the company we're working for: itemis. Into the bargain we're bronze sponsors for this years conference.
It is great to work for a company that really lives open source.

JDK Source Code on MacOSX

2011-03-01T10:41:00.005+01:00

After installing the latest update of Java for MacOSX Snow Leopard - must have been in March 2010 if my file system is not cheating on me - I missed the source code for the JDK classes. I remembered I had to install the Java Developer Package from the Apple developer center, but I couldn't find any. Consequently, I learned to live without the sources and forgot about the issue.

Yesterday I stumbled across a big performance issue in the upcoming Xtend2 compiler that only happened on my machine. Profiling yielded that it was because I have no local sources (another strange story).

So I decided to look for the developer package once again et voilà: Apple had been so kind to release it in the meantime. BTW, the timestamp says October 20th :-o

So here's what I did to get the MacOSX Java sources back (it's on your own risk, I disclaim any responsibility if you should break or machine)

1) Get an Apple Developper Connection account (it's free, but you have to register).
2) Login choose Java and download the Java for Mac OS X Developer Package matching your OS and Java version.
3) Install the DMG.

The install location of the JDK is somehow weird - e.g. you cannot directly open it in Eclipse's "Choose JDK location" dialog. To make it the default, I found it easiest to retarget the symbolic link pointing to the default JRE. You have to be super user in this case.

4) Open a Terminal and enter

cd /System/Library/Frameworks/JavaVM.framework/Versions
sudo rm CurrentJDK
sudo ln -s /Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents CurrentJDK

If Eclipse uses the default MacOSX JDK, you should now have sources.

Learn how to create a language for Android development using Eclipse Modeling

2010-10-28T19:11:00.004+02:00

If you are lucky, you have already registered for
Eclipse Summit Europe 2010 in Ludwigsburg, Germany. If not, I have sad news for you: It is sold out. Sorry.

If you're there, I hope you registered for our tutorial Creating a Language for Android Apps with Eclipse Modeling. A joint team from Obeo (Mikael Barbero and Stephane Begaudeau)
and itemis (Holger Schill, Dennis Hübner, and me) will introduce you to the basics of the Android SDK and show how EMF, Xtext, and Acceleo can be leveraged to simplify the development of Android Apps.
Bring your laptops, it's going to be a hands-on experience.

If you like this approach, learn how it works on larger scale in the talk Models To Go: How We Built a DSL for Mobile Apps With Tools From the Eclipse Modeling Project
by Peter Friese and Heiko Behrens who implemented the official ESE App for the iPhone.

Curious about what we have in mind for the future of Xtext? Then you must see Live Coding: Building a UI styling language for E4 with Xtext. Sven Efftinge and Sebastian Zarnekow will demonstrate Xbase, an Xtext based expression language bringing behaviour to your DSLs.
Sven will also talk about Dependency Injection which is the key to extensibility and an easy programming model, not only in Xtext.

Itemis will give two more presentations: Andreas Unger and Axel Terfloth from our embedded team will teach you on Developing Embedded Software with Eclipse, State Machines and Block Diagrams.
Nirmal Sasidharan will present Eclipse - an IDE for Organisational Change. I am sure you'll like these, too!

I am particularly looking forward to the keynotes, especially the one by Jeff Norris from NASA who already rocked this year's EclipseCon.

See you in Ludwigsburg!

Semantic Model Access in Xtext

2010-06-20T15:01:00.007+02:00

In Xtext, the parser creates the EMF-based semantic model or abstract syntax tree from the textual representation of the model. Many components, e.g. validation or outline, but also an interpreter or code generator work on this semantic model rather than on the textual representation. In this post, I want to introduce you to Xtext's APIs to safely read and modify the semantic model of an Xtext document.

Why do we need model synchronization at all?

In a running Xtext Workbench, there are a number of components which access the semantic model, i.e. the parser, the linker, the validator, the outline, the index builder etc. While some of these components are executed by the display thread, others like the parser or the indexer use different concurrent threads to not deteriorate the editing experience. If you for example want to have a consistent outline of your model, it is essential to keep other threads from modifying the model while the outline component reads it.

Why not use EMF Transaction?

Editors that use EMF Transaction usually employ a so called TransactionalEditingDomain that shields a ResourceSet with a lock and manages a transactional command stack. The Resources in the ResourceSet can be read safely - i.e. excluding any concurrent write operation - inside a Runnable that is passed to the TransactionalEditingDomain.runExclusive() method. Write access is only possible by issuing a command. A change listener throws an Exception if write operations are executed outside of write command.

This quite heavy-weight mechanism can be appropriate for pure model editors, i.e. editors modifying the model directly like the generated EMF tree editor, but experience shows that it is not easily integrated with other command frameworks. (If you don't believe this, just look at the way GMF deals with EMF Transactions, GEF commands and the Eclipse Operation history.)

Architecturally, an Xtext editor is a text editor in the first place. The commands on its undo/redo stack are the usual commands used in text editors. So instead of inventing yet another adapter technology, we headed for an easier synchronization mechanism.

How do I read a model safely?

Each XtextEditor uses an IXtextDocument to store its model. The IXtextDocument allows reentrant read/write access to the underlying semantic model by means of the two methods
readOnly() and modify(). Both take an argument of type IUnitOfWork(<T>, IXtextResource) which defines a method <T> exec(IXtextResource) that contains what you want to do with the model and allows to deliver a result of arbitrary type.

So here is an example of safely reading a model:

IXtextDocument myDocument = ...;
String rootElementName =  myDocument.readOnly(
new IUnitOfWork(){
       public String exec(IXtextResource resource) {
             MyType type = (MyType)resource.getContents().get(0);
             return myType.getName();
       }
 });

How do I modify a model safely?

Direct write-access on the document is usually only performed inside the framework. If you want to change a document by means of its semantic model, you should rather use an IDocumentEditor which uses the modify() method internally but takes care of synchronizing the node model, too:

@Inject
private IDocumentEditor documentEditor;

public void setRootName(IXtextDocument myDocument,
                     final String newName) {
documentEditor.process(
  new IUnitOfWork.Void() {
     public void process(IXtextResource resource) {
        MyType type = (MyType)resource.getContents().get(0);
        myType.setName(newName);
     }
  }, myDocument);
}

BTW, the QuickFix-API internally uses an IDocumentEditor, too.

PS:

In Xtext 2.0 we have changed the semantics of XtextDocument.modify() to use the former IDocumentEditor functionality. So the model write example now symmetrically becomes

public void setRootName(IXtextDocument myDocument,
                     final String newName) {
 myDocument.modify(
    new IUnitOfWork.Void(){
       public void process(IXtextResource resource) {
           MyType type = (MyType)resource.getContents().get(0);
           myType.setName(newName);
       }
 });
}

Xtext: Webinar and Eclipse Demo Camp

2010-06-07T10:30:00.004+02:00

Tomorrow (Tue, 8th of June) will be my Xtext presentation day ;-)

At 5pm CEST I will jump in for Sebastian in the Xtext Webinar. Sven and me will give a free one hour live seminar on Xtext introducing the framework and demonstrating its new fancy features in Helios. Moritz will assist us in answering your questions on the live chat. It's free and it's broadcast live via internet. Why not join?

If you're based in Germany's Ruhr area, you might want to visit the Eclipse Demo Camp in Dortmund. I will give another 20min demo of Xtext and - guess what - its new amazing features! But even for non-Xtext enthusiasts there will be nice demos, e.g on SAP's new graphical modeling framework "Graphiti", on developing Android apps with Eclipse and a lot more intriguing topics.

Finally, I plan to have my hopefully well-earned after-work pint in the Eclipse Stammtisch.

Xtext For Your Ecore Models

2010-03-31T16:44:00.007+02:00

The new M6 release of Xtext ships with a new component: The Ecore2Xtext Wizard.

Why should you use the Ecore2Xtext Wizard?

You want your models to be in a syntax that humans can not only read but also understand.
You want a model editor that offers all the convenience of a modern IDE.
You already have an Ecore model but don't know how to start with Xtext.
Your Ecore model is huge and you want a quick start with Xtext. You can easily fine-tune the syntax later on.

How do you use it?

Start the wizard by choosing New -> Xtext -> Xtext Project From Existing Ecore Models.
Select the EMF generator models¹ from your workspace for which you want a textual syntax and choose your root element's type.
Fill in all the language metadata on the second page of the wizard. Remember the file extension.
Click Finish and wait until Xtext has generated the two common Xtext plug-ins and the Xtext grammar for your language.
Run the MWE2 workflow located in the same directory as the grammar. Now Xtext generates the language infrastructure (parser, editor, formatter etc) .
Spawn a new Eclipse runtime workbench, create a sample Java Project, and open a new model file with the file extension you have chosen in the wizard. Play around and have fun with your new textual model editor.

¹ the genmodel is needed because we need the fully qualified names of the generated Java classes as well as the location of the Ecore file. The genmodel offers both of them.

Watch this short screencast to see it in action:

What is the generated syntax like?

Names of EClasses and EStructuralFeatures become keywords, containment is marked with curly braces, elements in lists are separated by commas, etc... Here's an example of an entity model in the generated language:

What if it doesn't work?

The grammar is the primary artifact of every Xtext language, but there are a couple of further services you might have to configure:

A IQualifiedNameProvider to define how the fully qualified name of an element is derived.
A IScopeProvider to define which elements are candidates for a cross reference.
...

Please consult the Xtext documentation for more information.

Another geekish meta-confusing example

All right geeks, Ecore itself is defined in Ecore, so let's generate a textual syntax for Ecore and see how Ecore looks in that syntax! Only two adaptions of the generated code where necessary to get this editor:

(The '^' chars are automatically added by Xtext to distinguish identifiers from keywords, which of course collide a lot in this example) It is certainly not as complete as EMFatic, and it has a quite verbose syntax, but it could be the starting point for a nice textual Ecore editor.

EclipseCon 2010 - Xtext everywhere

2010-03-25T22:08:00.005+01:00

It's the last day of this year's EclipseCon. My second time in Santa Clara and I even liked it better than last year: Many intriguing talks around Eclipse, OSGi, e4 and others, interesting people, much time for getting to know each other.

The itemis team has had a fair share on the program: With Moritz and Heiko, I gave a workshop in which we showed how to build an Xtext editor for the e4 workbench model. I also had a lightning talk on my favorite topic "Combining text and graphics in modeling editors". As always, you can download the slides to all talks from slideshare. We also had talks on Xtext, MWE2, Xpand and model-driven iPhone application development.

Xtext has been ubiquitous. We have seen a lot of cool Xtext editors in many talks. Quite a bunch of people came to our booth just to say thank you for the cool piece of software we've been working on for the past years. The absolute highlight was when Xtext received the Eclipse Community Award for the most innovative Eclipse project. It is so inspiring to get such a huge amount of positive feedback.

NASA also sponsored a competition of building a e4 client to control a small robot simulating the Mars Rover. Peter and Heiko have decided not to sleep but to rather build an iPhone client instead. Even though it was not based on e4, people were really impressed. Watch Jeff Norris from NASA driving the rover with an iPhone! By the way, Jeff gave the best keynote I have ever seen on "Rocket Science and the Republic".

Tonight will be the European Reception sponsored by itemis and the conference will end. We'll have another day in San Francisco before returning home to Germany. I hope I will make it next year again. Thanks to the organizational team for giving such a wonderful conference.

Eclipse Summit Europe 2009 retrospective

2009-10-30T10:39:00.003+01:00

Attending Eclipse Summit Europe 2009 once again felt like a big family meeting. It is always a pleasure to meet people you usually only correspond with electronically in person. The organization was once again almost perfect and the food excellent. Thanks a lot to the organizers and sponsors!

We had a very productive project meeting for the EMF Index project, clarifying a lot of critical points and further aligning the efforts and requirements of the involved parties.

Markus, Sebastian, Karsten and me were impressed by the large number of about 50 participants in our workshop on Domain-specific Languages with Eclipse Modeling. The slides are now online at slideshare, just in case you're interested. With such an audience it was of course a little bit difficult to make it a real hands-on experience, but I think we at least managed to leave a good impression on the presented toolchain.

Jos's and my talk on Combining text and graphics in modeling tools was also well attended, and from the quality of questions that were asked I guess our message has been understood. The slides are also available at slideshare.

Apart from a number of really impressive talks, the thing that most impressed me was SAP's graphical editing framework. Instead of using a code-generation approach it rather focusses on an provider-based Java API. They are currently in the process of adapting it to EMF and their plan is to make it open source. I hope they really do, because it seems to have the potential of greatly reducing the complexity of creating graphical editors.

GMFTools Part 2: Sharing an EditingDomain

2009-10-25T14:51:00.003+01:00

In this blog, I will elaborate on how GMFTools facilitates to share the same instance of an EditingDomain across multiple diagram editors.

What is an EditingDomain?

In GMF, each diagram editor works on its own instance of a so called TransactionalEditingDomain. TransactionalEditingDomain is a concept from EMF Transaction. In GMF, it contains an EMF ResourceSet holding the diagram model, its semantic model and all referenced models as well as a command stack for undo/redo support. In addition, each editor registers a WorkspaceSynchronizer to its resource files, making sure external changes are synchronized with the editor's content.

Why share the EditingDomain?

In the default setup, problems occur if two editors operate on the same resources: If both editors change the same resource, saving one will overwrite the changes of the other. This situation already happens when you're using the Related Diagrams feature in the gmfmap model: On double click, it will open a new diagram that is saved in the same resource but in a different editing domain. As the original editor is still open, conflicts can arise quickly.

Another reason for sharing the editing domain is to save memory and performance, especially if you're working on big models with a couple of editors.

In many cases you might want to see changes immediately in all editors without having to save first, e.g. when your editors show different parts or aspects of the same model. GMF has already built-in support for that as it uses EMF's notification mechanism to synchronize the notation (diagram) model with the semantic model.

Consequences of sharing an EditingDomain

Sharing the editing domain across several editors has a number of consequences

The editors will also share the same command stack. Undo/redo becomes a global operation and can therefore affect other editors than the currently active one.
For reasons of simplicity, all editors should be saved synchronously, and they will all be either dirty or clean at the same time.
You should no longer dispose the editing domain when closing an editor. That means, to avoid memory leaks you need strategy for unloading unneeded resources.
The command stack will keep references to unloaded model elements, too, so you might want to have an garbage collecting strategy here as well or at least keep the command history short.

Solution in GMFTools

The solution in GMFTools is based on a WiKi page of GMF and a couple of newsgroup entries combined with our own experiences. It has been recently refactored to reenable the WorkspaceSynchronizer.

It comes in a number of aspectual template changes for the GMF code generator, an additional runtime plug-in and tool support for fixing the type registry, such that it is rather easy to consume even if you're not too familiar with the GMF runtime. Note that so far we have only been using it to generate plain diagram plug-ins, i.e. not for GMF's RCP generator.

The major changes are

Redirect all creation statements of an editing domain to a new utility class and the dispose statements to an unloading tool.
Make sure to use consistent element types.
The common behavior of all XXDocumentProvider.ResourceSetInfo has been extracted to avoid synchronization feedback loops.

If you're interested in the details have a look at the WiKi-page.

GMFTools Part 1: UI Extensions

2009-10-09T18:18:00.006+02:00

This is the first of a short series of posts on GMFTools.

The Graphical Modeling Framework is a powerful framework for the development of graphical editors for EMF-based models. It's based on EMF and GEF and uses a model-driven approach for designing the editors.

Building graphical editors is a complex task. While GMF tries to facilitate that procedure, its abstractions are sometimes still a little hard to grasp, and the generated results often need manual fine-tunig to meet end-user expectations. I am a user, not a developer of GMF. Mymain concern is getting things done in the projects I am working on. That's why I sometimes bend GMF to do what I want it do, rather than use it the way it is meant to be used. That fact makes it somehow hard to contribute back to the GMF project. Still, me and my colleagues take a lot of benefit from using GMF.

GMFTools

As a long term user of GMF, I started to collect code, tools, samples and several tipps and tricks in the GMFTools project about a year ago. In the meantime, the project has attracted additional committers and it has become quite a useful collection of real-world solutions around GMF.

GMFTools roughly consists of three components

UI-Extensions making GMF easier to use.
Runtime extensions that add new functionality by means of additional classes and generator template changes.
Examples demonstrating the use of the runtime extensions.

The GMFTools Button

The first thing that may catch your attention after having installed GMFTools is a new GMF button in your button bar. It is meant to make GMF development easier and performs a bunch of actions on your GMF projects, including running the GMF code generator. To see what kind of actions, open the preference page for GMFTools. Each action can be enabled and disabled separately.

Most of the actions are self-explanatory. You may wonder why I want to delete the gmfgen model and the diagram code before re-generating. The reason is that by deleting the generated artifacts before re-generation, I circumvent all reconciliation steps (including JMerge). I have very bad experiences with reconcilers in general and so I prefer not to mix manually written and generated code. Some people have called me a "purist" for this attitude, but from my experience a clean separation will pay in the long run of a model-driven project.

As a consequence gmfgen model becomes a temporary artifact in the whole code generation procedure. To be able to modify the gmfgen model nevertheless, I have introduced a model-to-model transformation that is performed before generating the actual diagram code from the gmfgen model. This transformation is performed using an Xtend file (both oAW and M2T work) which is persisted next to your GMF design models.

The fix of the type registration will be covered in a post on shared editing domains.

In the middle of the preferences, you can manipulate your current set of GMF models (might not be the best name), i.e. the combinations of ecore, genmodel, gmfgraph, gmftool and gmfmap models you need to generate a GMF editor, as well as the Xtend transformation. These sets can also be provided by means of *.def files that can be stored in your workspace next to the design models.

By a single click on the GMF button, all enabled actions are executed on the currently / last selected models. In its drop-down menu you can access all your editor model individually. That really speeds up GMF development significantly, as you no longer have to find your way through the popup menus of different files. Nevertheless, individual actions can still be executed from the popup menus of the respective files.

That's all for today. Stay tuned for more.

Eclipse Summit Europe 2009

2009-10-08T18:49:00.003+02:00

I am looking forward to Eclipse Summit Europe 2009 in Ludwigsburg, Germany.

My colleagues from itemis and me, we're once again going to have our share:

Sebastian Zarnekow, Karsten Thoms, Markus Voelter and me are going to give a tutorial on Domain-specific Languages with Eclipse Modeling, in which we show how to set up your own easy-to-use MDSD toolchain.

In the short talk Combining Graphics and Text in Modeling Tools, Jos Warmer and me will be elaborating on mixing concrete syntaxes for the same model using state-of-the-art modeling tool frameworks such as Xtext and GMF.

In the talk Xtext - From Galileo to Helios, Sven Efftinge and Sebastian Zarnekow are presenting the future plans for Xtext.

Finally, Andreas Graf and Markus Voelter are going to talk on Leighweight Model-Driven Development for Embedded Systems.

So, maybe there's something in for you, too?

MacOSX window trouble

2009-10-05T08:00:00.003+02:00

Clever people know that cleaning your keyboard while your computer is switched on might be a bad idea. I did anyway, and as a result my Eclipse window looked like this:

For the non MacOSX experts: You won't be able to click on the right restore button, and there is no such menu entry anywhere. Luckily, Eclipse can be restored using Window->New Window (thanks for the hint, Sebastian). Restarting the application or the computer would not work.

But how's that supposed to work in MacOSX anyway? I found a couple of Applescript solutions, but nothing really user-friendly in the internet. I couldn't even figure out how I got into this situation. Any ideas?

EMF Index

2009-09-18T15:26:00.002+02:00

Work on the Eclipse project EMF Index has started. As the project lead, I am proud to present our new website http://eclipse.org/emfindex.

It's a bit plain - because I made it myself and I am not much of a designer - but still looks quite slick, as it is based on the Nova CSS. Heiko's webpages on Xtext have been a useful template.

Dennis and Sven have worked hard to finally get the automatic build running. You can download the latest snapshots

the interim build update site: http://download.eclipse.org/modeling/emft/emfindex/updates/interim/
the nightly build update site: http://download.eclipse.org/modeling/emft/emfindex/updates/nightly/

The current implementation is based on EMF. SAP is working in parallel on another implementation using tables and a paging mechanism.

Xtext in Essen aftermath

2009-08-24T23:01:00.008+02:00

Thursday was the hottest day this summer in Germany. But despite 30° C and thunderstorms a bunch of Java enthusiasts made it to the meeting of the ruhrjug, the Java user group in Essen (Germany).

Having a talk on Domain-specific Languages with Xtext was once again a refreshing experience, as the audience appeared very interested and posed a lot of intriguing questions. The whole thing has been recorded on video (sorry, it's in German), so you'll be able to see me sweating as soon as I have the link.

Thanks to Heiko Sippel and Peter Rossbach who organized the meeting and Prof. Dr. Michael Goedicke our host from the University of Essen/Duisburg at that night.

By the way, if you're hilarious about Xtext, don't forget to join our Model Prize Laureate competition and win a Google Phone, a ticket to the Eclipse Summit Europe or other fancy and geeky prizes!

PS: The video is now online. Watch me sweating at http://www.ruhrjug.de/videos/gse.lectures.app/Talk.html#Xtext.

Xtext in Essen

2009-08-17T09:19:00.003+02:00

I'll be giving a talk on Domain-specific languages with Xtext to the Java User Group ruhrjug in Essen (Germany), Thursday the 20th of August, 18:30h.

So if you're based in the Ruhr area, bored by your summer holiday and keen to learn more about DSLs in practice, why not give it a try?

To avoid finding yourself in the wrong location, please note that this is the first ruhrjug event at the new location Glaspavillon Campus Essen.

Source code for the screencast of Xtext and GMF

2009-07-28T14:56:00.004+02:00

Having received a lot of positive feedback for my last post, I finally found the time to make the source code available. You can find it in the SVN repository of the GMFTools project.

I have put the installation instructions here.

Note that this is proof-of-concept code rather than production quality. See my previous post for implementational details. Also note that two open bugs

currently limit the fun a little bit, but we're at least working on the Xtext part.

Synchronized editors with TMF/Xtext and GMF

2009-06-21T18:47:00.002+02:00

Well, here it is, the screencast showing a textual TMF/Xtext and a graphical GMF editor synchronized on the same model.

The example has been implemented with only a few changes to generated code: In Xtext, the following modifications were applied:

A Formatter to define where to use what kind of whitespace, when the textual representation is derived from the semantic model.
An IFragmentProvider that generates name-based fragments (IDs) for elements in an Xtext resource. That way, the correspondence of graphical nodes to semantic elements is preserved even if you delete a preceeding entity.
An AbstractEntitiesJavaValidator has been implemented for Java based validation

On the GMF side:

In the mapping model, I had to use feature initializers to make sure names are initialized properly on creation, to always have serializable models.
In the generator model, I had to manually set the domain genmodel and the file extension.
In the generator model, I enabled validation decorators and printing, and added the plug-in de.itemis.gmf.runtime.extensions from the GMFTools project containing a more sophisticated layout.

Additionally, I added a bit of glue code:

An action to navigate from an EditPart to the textual representation, using Xtext's NodeAdapter.
A listener that warns the user if (s)he's about to change a file that has already been changed in another dirty editor, and allows to abandon the changes.

The editor are synchronizing on save, to avoid GMF's canonical edit policies pruning nodes/edges belonging to temporarily lost elements.

Xtext plays well with EMF. It registers

A resource factory for a specific XtextResource implementation that encapsulates the parser (text->model) as well as the serializer (model->text).
An EValidator with a declarative Java implementation

Slides from Xtext Workshop at Code Generation 2009

2009-06-19T12:11:00.002+02:00

Code Generation 2009 has been a lot of fun. Yesterday, Moritz, Sebastian and me gave a hands-on workshop on Xtext. Participants seemed to like it and we could even convince Steven Kelly from Metacase to give it a try. I've uploaded the slides to slideshare, so if you wish to learn something about Xtext, you can have a look at it here.

Back to Kiel, we are now sweating to give Xtext the last polish before it is released with Galileo.

CodeGeneration 2009

2009-06-16T14:58:00.003+02:00

I am back at Cambridge (UK) for this year's Code Generation conference.

The itemis-Kiel team already arrived yesterday, and after a nice walk through the town and some fish and chips, I finished a showcase with a GMF editor on an Xtext model. So be prepared for another converging editors screencast soon :-)

The conference started this morning. Up to now, I have heard two talks: First, Kathleen Dollard from AppVenture talked about Template Specialization. Kathleen referred to the .NET code generation languages and their specific problems, e.g. with respect to modularity and extensibility. To me it looked like we've got more comfortable solutions in the Eclipse/Java world. Then, Sven and Sebastian talked about Challenges in DSL Design. They elaborated that todays external DSLs usually stop at modeling behavior because of the lack of an embeddable expression language. Looks like that's going to be one of the goals in the next version of Xtext. Right now I am guarding the itemis booth for a while, just to join the case study by Karsten and Heiko on their MDSD projects at Deutsche Börse AG.

Despite all prejudice against British food, catering is excellent. Thanks to the perfect organisation by Mark Dalgarno and Andy Moorley, we're going on a traditional punting trip along the river Cam tonight. Should I have brought my wetsuit?

JAX is over, now head for Code Generation

2009-04-30T17:25:00.006+02:00

The JAX 2009 conference in Mainz (Germany) was once again big fun: A good opportunity to meet lots of intriguing people and listen to entertaining and informative talks in a beautiful location at the river Rhine. I've just uploaded the slides of the talks I gave, so if you're interested, have a look at EMF - Beyond the Basic or Eclipse Modeling Overview.

If you're keen on modelling with double 'l' :-), I recommend to join the upcoming CodeGeneration 2009 in Cambridge (UK), 16th-18th June 2009. Next to a bunch of well known speakers from industry and research, my colleagues from itemis and me are also going to have our share on the programme, e.g. Challenges in DSL Design, Mastering differentiated MDSD requirements at Deutsche Boerse AG, MDD: The Good, The Bad and The Ugly, MDD: The Best, The Worst and The Ugliest, Language Definition, Extension and Composition with MPS and an Xtext Workshop.

Talks at JAX Conference in Germany

2009-04-17T09:19:00.002+02:00

Sven and me, we're going to give some talks on Eclipse Modeling, DSLs and Xtext at the JAX conference in Mainz (Germany) next week:

Eclipse Modeling - Overview
Sven Efftinge, Jan Köhnlein
Tue 21/04/2009, 10:00-11:15h

Code generation in agile Projects
Sven Efftinge, Jan Köhnlein
Tue 21/04/2009, 16:45-17:45h

Xtext
Sven Efftinge
Wed 22/04/2009, 10:15-11:15h

EMF: Beyond the Basics
Jan Köhnlein
Wed 22/04/2009, 16:15-17:15h

Hope to see you there!

Xtext, Generic Editor and EMF Index at EclipseCon

2009-03-24T23:50:00.002+01:00

Just finished our talks at EclipseCon.

First, Sven and me talked about the new TMF/Xtext. The room was so crowded that some listeners even had to sit on the floor. Presenting was really fun and given the feedback people are really excited for Xtext. So we are, even though Sven has a bad throat and almost lost his voice ;-)

Given the good resonance, we're trying to organize a BoF session on Xtext tomorrow. Stay tuned for exact time and location.

Sven had a 10 minutes talk on the Generic EMF Editor then, and showed the Editor, Xtend and Xpand. I think, it's a good idea to point people at the fancy features of the oAW languages, such as polymorphic dispatch and higher-order functions.

Finally, I gave a 10 minutes talk on EMF Index. I have the impression people were quite curious about that topic as we already mentioned that in our Xtext talk. I tried to prepare the slides in the presentation zen style, and I can just conclude that presenting is so much more fun than having a clutter of bullet pointed list. I hope, it's the same for the viewers. And I exactly hit the 10 mins :-)

EclipseCon is really great. You really meet lots of people in person you have only known from blogs or mailing lists. Having had my share, I can now relax and join the other talks on so many other interesting topics.

EMF Index Creation Review

2009-03-10T17:42:00.003+01:00

Tomorrow will be the creation review for the new EMFT subproject EMF Index. I am really looking forward to my first Eclipse project leadership and I hope everything will work out fine at the review.

EMF Index aims at indexing EMF models to allow scalable modeling tools with JDT-like comfort. So, if you have any objections against EMF Index, speak now (in the EMFT newsgroup) or remain silent forever ;-)

I am also glad to have the opportunity to present EMF Index at EclipseCon 2009 in Santa Clara. Looks like many of the interested parties will attend. I am going to give another talk together with Sven on Next generation textual DSLs with Xtext. It's also my first trip to the US, which makes me even more excited.

Xtext Success Story

2009-02-02T11:24:00.003+01:00

Just returned from a workshop in Switzerland. One of the guys there managed to

Get acquainted with and install Eclipse.
Install and learn oAW Xtext.
Define a grammar and generate the code.
Deploy the editor at the customer's side.

All of that within 5 days. What does that mean

That guy is really a wizard.
Eclipse is very easy to install and use.
Xtext can really give you a head-start into modeling.

It feels so good to have such a mighty toolstack at hand :-)

OOP 2009

2009-01-28T12:23:00.003+01:00

I am at the OOP 2009 conference in Munich. Lots of technical talks on software engineering, but soft skills are also a big topic. Even though our both is not really 80 square meters as promised, we are having lot of fun.
Yesterday, Sven and I had a talk on the introduction of three DSLs in a customer project: A textual DSL based on Xtext describing the domain model, a graphical DSL based on GMF for defining form layouts and an internal Java DSL for validation. I think we managed to entertaining the audience, as we made fancy slides in the "Presentation Zen" style. Measured by the amount of questions the talk was a success.

Proposal for new Eclipse Project: EMF Index

2009-01-06T09:31:00.003+01:00

In the Modeling Symposium at Eclipse Summit Europe 2008 we discussed the necessity of an index for EMF models. Such an index would allow efficient queries for EMF model elements without actually loading the model resources, which is an enabling feature for powerful EMF modeling tools.

The proposal is now online. Please use the EMFT newsgroup for discussion. I am looking forward to your feedback.

How to make an xtext language reference another by nsURI

2008-11-27T17:28:00.003+01:00

In principle, Xtext allows two languages to refer to each other by means of the importMetamodel feature. If you specify the imported meta-model by means of a file URI, everything works out of the box. Unfortunately, file URIs are not suitable in many scenarios, so something less physical would be appropriate.

Due to a certain mismatch between the way openArchitectureWare (and thereby all the language's Xtend and Check files) and EMF access files and handle EPackage registration. The following describes the way to go in the version of Xtext that is shipped with oAW 4.3.1. Note that in TMF/Xtext we will provide easier support by means of classpath relative URIs.

Example

We consider the following two DSLs asl and bsl, where asl references bsl:

asl:

importMetamodel "http://www.example.org/my/bsl" as mybsl;
A:
 (imports+=Import)*
 (bs+=BRef)*;
Import:
"import" file=URI;
BRef:
"a" name=ID "b" b=[mybsl::B];

bsl:

B:
"b" name=ID;

To allow such cross-language reference, you have bsl has to be installed in the workbench you use for editing asl.

Install an xtext language

This usually boils down to deploying the language plug-in into the Eclipse workbench, e.g. by exporting it as deployable plug-ins and fragments into the dropins folder of the Eclipse installation.

There is one issue with the way xtext registers its meta-model. The EPackage is added to the EPackage.Registry programatically in the generated MetaModelRegistration class, such that we can call it inside or outside a running Eclipse. If running inside Eclipse, the MetaModelRegistration is called by the Activator of the language plug-in. This can be too late, as other plug-ins might not use the language but the meta-model, and rely on it to be accessible from the EPackage.Registry.

We cannot use EMFs dynamic_package extension point, as it requires the ecore file to be in a plug-in neutral folder. This is not the case in Xtext, as it stores the generated file in a source folder, which is no longer present once the plug-in is deployed.

There are two ways to solve this problem
1) Run the EMF generator to generate code from the ecore model. This will also register the generated EPackage Java class to the generated_package extension point of EMF.
2) Register a proxy class to the generated_package extension point, that implements EPackage (empty methods) and returns MetaModelRegistration.getEPackage() as its eINSTANCE. To ensure that the model is really loaded, you should delete the registered proxy in the static initializer and set the right resource loader before registering the package.

org.example.bsl.EPackageProxy:

package org.example.bsl;
...
public class EPackageProxy implements EPackage {
  static {
    ResourceLoader cl = ResourceLoaderFactory.createResourceLoader();
    try {
      ResourceLoaderFactory
        .setCurrentThreadResourceLoader(new ResourceLoaderImpl(
           EPackageProxy.class.getClassLoader()));
      EPackage.Registry.INSTANCE.remove("http://www.example.org/my/bsl");
      MetaModelRegistration.register();
    } finally {
      ResourceLoaderFactory.setCurrentThreadResourceLoader(cl);
    }
  }

  public static final EPackage eINSTANCE = MetaModelRegistration
       .getEPackage();

  public EClassifier getEClassifier(String name) {
    throw new UnsupportedOperationException("Method not implemented");
  }

  // remaining methods of EPackage
  ...

plugin.xml:

  <extension point="org.eclipse.emf.ecore.generated_package">
     <package class="org.example.bsl.EPackageProxy" uri="http://www.example.org/my/bsl">
     </package>
  </extension>

Referencing an installed xtext language by nsURI

The xtext generator starts a new plain Java VM, and therefore does not have access to EPackages registered via extension points. That's why you have to explicitly register the referenced metamodel of bsl in the generator workflow of asl. Into the bargain, we have to register bsl's resource factory. Write a class

RegisterBslHelper:

package org.example.asl;
...
public class RegisterBslHelper {

   public RegisterBslHelper() {
     EPackage package1 = org.example.bsl.MetaModelRegistration.getEPackage();
     package1.eResource().setURI(URI.createURI(package1.getNsURI()));
     org.example.bsl.ResourceFactoryRegistration.register();
   }
}

and call it in the generator workflow generator.oaw:

<workflow>
  <property file="'generate.properties'/">
  <bean class="org.example.asl.RegisterBslHelper">
  <component file="'org/openarchitectureware/xtext/Generator.oaw'" inheritall="'true'/">
  </component>
</workflow>

Also make sure, that the my.asl plug-in has a dependency on my.bsl and reexports that.

Started GMFTools project

2008-10-20T15:52:00.001+02:00

I've worked with GMF for several years now, and I've built quite a bunch of graphical editors using it.

On my way, I've come along several issues, problems and annoyances of the GMF framework. Some of these may be a matter of personal taste, others are just reoccurring topics and tasks, which unfortunately have never been really focused within the GMF project. As these are sometimes hard to separate, I've decided to collect my ideas, extract reusable solutions and share them by making them open-source. This way, I hope to share knowledge with other GMF users, get feedback (maybe even by the committers), provide examples for beginners, and of course make my own life easier.

Have a look at it at http://code.google.com/p/gmftools/, and, if you like it, feel free to use it. But please don't expect me to provide extensive support. Main topics covered are

Sharing an editing domain among several editors
Make GMF's development process easier, e.g. by bypassing unreliable reconcilers and provide a very simple UI to the code generator.
Additional layouts, e.g. make labels fit into ellipses.
How to implement non- or semi-canonical diagrams.

Of course your comments are very welcome.

Maybe there are even more people around willing to share GMF solutions...

Code Generation 2008 review

2008-07-03T14:39:00.001+02:00

The Code Generation 2008 in Cambridge (UK) has been real fun. Karsten, Sven, Peter and me, we have met a lot of interesting people from the model-driven / DSL world, and have heard lots of interesting views and news on code generation.

The best thing in a conference on code generation is that the participants are already convinced of the benefits of modeling, so you don't have to explain every time from the very beginning why you think modeling is a good thing.

Last but not least, our workshop on openArchitectureWare was very successful and we has been rated top by the participants. It feels good to be assured that we are working on the right things.

CodeGeneration 2008

2008-06-26T10:41:00.000+02:00

I am currently attending the CodeGeneration 2008 conference at Cambridge (UK).

It is very inspiring to meet so many people involved in model-driven software development. Many of them come from the Microsoft DSL tools world which apparently has not evolved a lot in the recent past. People show a lot of interest in oAW and Eclipse Modeling techniques.

Yesterday we had a very vivid gold fish bowl discussion on the evolution of DSLs. Many of the emerging problems seem to be resolvable by better tooling. That just convinced me that we are working on the right topics in the current development of Xtext and oAW5.

Well, of course there are still a bunch of people around promoting MDA with all the UML and OMG stuff. It appears to me that simple things have a tendency to become rather complicated with that approach.

Looking forward to our hands on workshop on Eclipse Modeling tools tomorrow.

New Article on Textual DSLs with EMP

2008-06-03T16:45:00.000+02:00

Peter, Sven and me, we have composed an Eclipse article on how to create your own textual DSL using tools from the Eclipse Modeling Project (EMP). It covers the definition of a grammar using Xtext, generating, running and customizing the DSL editor, adding constraints with Check and generating code with Xpand. You can find it here.

We are convinced that the described approach one of the most pragmatic ways of designing DSLs and implement code generators. If you have just a little bit of experience with the described technologies, creating your own external DSL becomes nearly as natural as writing Java code.

Tuning ELists

2008-03-18T09:23:00.000+01:00

Just solved a serious performance problem. I programmtically constructed a rather big EMF model. It took ages so I started a profiler: Most of the time was spend in the BasicEList.contains(EObject) method.

This is due to the fact that the corresponding EReferences have the unique flag set to true. EMF makes sure each element appears only once in the list of that reference. This is good, but performs poor for big growing lists.

As I construct the model from scratch I can make sure there will be no duplicates. So instead of

parent.getFeature().add(child);

I cast to BasicEList and call

((BasicEList<EObject>) parent.getFeature()).addUnique(child);

In my case, that reduced the execution time to a fifth !

Testing Trees

2008-03-07T17:25:00.000+01:00

Working on parsers a lot recently, I have to write quite a bunch of tedious unit tests. Each of these tests analyses an EMF AST model which is the output of the parser. It checks if all nodes are at the right location and if all properties are set correctly. The tests look awful and debugging is a nightmare.

Using Xtext, it is quite easy to create a DSL for tree comparison. I can now describe expected tree results as

Extension {
name=Identifier(value='foo')
params=[
DeclaredParameter {
name=Identifier(value='this')
type=Identifier(value='Object')
},
DeclaredParameter {
name=Identifier(value='that')
type=Identifier(value='Object')
}]
}

where Extension, Identifier and DeclaredParameter are EClasses, name,params and type are EReferences and value is a attribute.

Writing such a DSL and an interpreter doesn't take you a day and will save you a lot of time and mental sanity in the future.

Converging Model Editors

2008-02-22T17:39:00.000+01:00

Yesterday, Sven implemented an EMF Resource that serializes its content in Xtext format. We combined it with a graphical editor and the new EValidator adapter for oAW check. Generating everything, we finally got three synchronized editors all showing different representations of the same resource: Graphical, in Xtext and in an Ecore tree. Even complex changes in one editor were automatically transferred to all other editors on save and two of the editors even used the same checks for validation.

That really rocked.

And it shows how great EMF and oAW really are. In the future, it should be easy to write DSLs with mixed representations, e.g. a graphical part for the element connections and a textual part for the details.

I am really looking forward to work on a closer integration of oAW and EMF. There's so much potential.

Advanced GMF

2008-02-20T11:19:00.000+01:00

Having collected about two years of experience with Eclipse's Graphical Modeling Framework, I am now trying to summarize what could be improved or added to the framework. These are my favorites

Support for a singleton editing domain (keep all semantic and diagram resources in the same resource set)
Support for non-canonical diagrams (multiple diagrams for the same semantic model)
Enable the OpenDiagramEditPolicy (linked diagrams)

Most of these issues can be implemented without touching GMF runtime code, i.e. by means of aspectual template changes and extensions. But as these are really fundamental and reoccurring topics, I'd rather see them as base functionality inside the original framework. Maybe I can push the GMF project in that direction?

Here it is...

2008-02-19T16:28:00.000+01:00

Finally, web 2.0 has reached me. So here is my new blog.