Founding TypeFox

After 8 exciting years as an employee at itemis, I eventually decided to become my own boss. Together with Sven I founded a new enterprise named TypeFox. From the team constellation you might already have guessed it: TypeFox is going to be all about Xtext, Xtend, languages and tools.

Of course, we will continue the development of Xtext, Xtend, FXDiagram etc. at TypeFox, and provide professional services and support around these topics on demand.

Check out our shiny new website at http://www.typefox.io. It also hosts a new blog on which we are going to post interesting articles about Xtext & Co on a regular basis, starting with contributions by Lorenzo Bettini, Sven and yours sincerely. Let us know what you think!

Happy Xtext-ing!

Graphical Views for Xtext

Xtext provides you with a powerful IDE and a rich featured text editor for your domain-specific language with little effort. But sometimes, a picture says more than a thousand words: You want to have some additional graphical representation of your models, a set of diagrams.

Diagrams are superior to code when it comes to high-level views. But while programmers can easily cope with files that contain several hundred lines of code, the same amount of information usually blows a diagram and destroys all its suggestiveness. Diagrams with just a few nodes and edges showing on a certain aspect of the models only are best fit for human readers. Such aspects are often spread across various model files. So in order to add the best value for the language users on top of an Xtext infrastructure, we need to allow them to create multiple diagrams, each highlighting just a subset of model information, picked from multiple model files. In other words, diagrams that have a completely different structure than their associated textual models.

Traditional graphical editing frameworks focus on editing the underling model through the diagram.
But synchronizing the model changes from textual and diagram editors is very hard if their content's structures differ. In most cases, the integration will lead to major usability quirks like unexpected editor behavior, forced save operations, blocked editors or even data loss.

So rather than working around the hard challenges of integrating graphical and textual model editing, we can leave model modification to Xtext. For the graphical stuff we can concentrate on diagram editing and leave the underlying model read-only. This way we can spend our energy on the things that really matter to the user, like easy and useful ways to populate diagrams or best visual appearance.

In Eclipse, one could build such graphical views using Zest or GEF. If model and diagram do not differ too much in structure, a small code generator targeting GraphViz is a very simple solution with high quality output.

The general integration with Xtext is covered in a follow up post.

The following screencast shows another solution for an Xtext-based domain model language. The graphical editor is using FXDiagram, a diagram framework based on JavaFX. FXDiagram offers a very smooth user experience, excellent rendering, support for touch-pad gestures, animated undo/redo, diagram persistence, export to scalable vector graphics and much more. If you are interested in learning more, feel free to contact me.

Using Xcore in Xtext

With Xtext you can easily create your own textual language. The structure of the language is defined in an Ecore model. This model can be automatically derived from the grammar, which allows quick turnarounds in the beginning. But in the long run, this model becomes an increasingly important API to the language. You want to fix it and make it a first class artifact: You are switching from an inferred Ecore model to an imported one in the grammar.

Traditionally, you use EMF's tree editors to edit Ecore models. That can be cumbersome as the tooling is not the nicest to use. Furthermore, the Ecore model only describes the declarative part. Behavior, such as the body of EOperations or the code for derived EStructuralFeatures has to be woven in either from additional models or directly in the generated code. These and more issues are addressed by Xcore. Xcore allows to specify Ecore models textually, including the behavioral parts and the code generation parameters. Having a single source of information facilitates the maintanance of such a model drastically. Xcore is shipped with EMF.

In the upcoming Eclipse release 4.3 (Kepler) Xcore and Xtext can be used together. Here is a step-by-step example how to do this with Xtext's "Greetings" language:

1. Create an Xtext project File > New > Project > Xtext Project. The defaults are fine. This will create the usual four projects for your Xtext language in your workspace.
2. By default, Xcore generates its code to the folder src-gen. The same folder is used by Xtext and will be wiped each time you regenerate the language from the grammar. To avoid loosing data, choose a separate output folder for Xcore: Eclipse/Window > Preferences > Xcore > Compiler > Output Folder > Directory > ./emf-gen
   
   
   
3. Create a new folder model in the root of org.xtext.example.mydsl and file Greetings.xcore inside that folder. Our Ecore model consists of an EPackage org.xtext.example.mydsl, two EClasses Model and Greetings, a containment EReference greetings and an EAttribute name. In Xcore, this looks like
:
   
   
   
4. Open the grammar MyDsl.xtext. By default, the Ecore model myDsl is generated from the grammar rules. We want to replace this with the Ecore model specified in the Xcore file:
   
   
   
5. We have to load the Xcore model in the workflow GenerateMyDsl.mwe2 of the language generator. Add an appropriate loadedResource entry to the language section:

   

   module org.xtext.example.mydsl.GenerateMyDsl
   ...
   Workflow {
     ...
     component = Generator {
       ...
       language = auto-inject {
         loadedResource =

   "platform:/resource/${projectName}/model/Greetings.xcore"
         uri = ...
   

6. You have to add a dependency to org.eclipse.emf.xcore in the MANIFEST.MF of the project.
7. Now generate the language infrastructure Run As > MWE2 Workflow. There should not be any error.
8. Make sure that all folders will be correctly deployed. Your build.properties file should look like this
:
   
9. Launch a new Eclipse workbench Run > Run Configurations > Eclipse Application > Launch Runtime Eclipse and enjoy your language in action.

For the geeky fun of it: As Xcore is itself implemented in Xtext with an imported Ecore model, this lays the foundation to replace Xcore.ecore with Xcore.xcore and thereby bootstraping it.
Sorry, I couldn't resist ;-)

'X' Is For Abstraction

We at itemis have created a bunch of projects with an ‘X‘ during the last years: Xtext, Xtend and Xbase. In this blog post I am trying to elaborate the different use cases for each of them.
 

It all starts with Java...

...which is a nice language understood by many programmers worldwide. A giant ecosystem and a vivid community as well as great IDEs are keys to its success.

But Java has a couple of crucial problems: Its syntax is inflexible and very verbose, making fluent APIs the closest you can get to domain-specific languages. Design patterns and structural conventions as JavaBeans have to be manually implemented over and over again with lot of error-prone boiler plate code. Frameworks require a big deal of XML pointing to Java classes, often ignored by the static analysis at compile time. IDEs can help us here, but they are usually limited to scaffolding or a single way of using a framework. The diagnosis is: Java is lacking the right means of abstraction.

All technologies presented in the following enable you to define your own set of abstractions on top of Java. The solutions differ in syntactic flexibility, turnaround times, required user skills and multi-platform coverage.

External DSLs (Xtext)

Xtext is a framework for external, textual, domain-specific languages. Xtext makes it easy to build an entire IDE for a completely new language, including your own code generators or interpreters to execute it. The Xtext homepage lists a lot of example projects.

When should you use Xtext? First of all, when you need a maximum of syntactical freedom. As Xtext DSLs are external they are defined by their own grammar, thus not constrained by the syntax of a host language.

Second, use plain Xtext if your language has no correspondence to Java or if you want to avoid dependencies on JDT at all cost. Languages that target different platforms at the same time are most likely based on a plain Xtext-based language, too. The technical skills needed to work with a Xtext-based language IDE is relatively low. I personally do not believe in "programming business men". But Xtext has been successfully used for non-technical, purely domain-oriented languages.
As the generated IDE is already very powerful by default and can be customized easily, some people even use Xtext to build the IDE front end for an existing language with an existing compiler.

If you change the grammar, you have to regenerate the language infrastructure and redeploy the language's plug-ins to the user's machines. The latter can be a challenge in some scenarios.

Mostly structural languages with simple expressions only will go smoothly. A few complicated expressions can pragmatically be integrated using the common integration techniques (generation gap pattern, black-box literals, protected regions, etc.). But all of these raise the complexity, break the abstraction, and are hard to maintain. If expressions are the rule and not the exception, consider

Java DSLs (Xtext with Xbase)

Under the codename Xbase, we have developed a rich expression language, that you can embed in your Xtext-based DSLs. It reuses Java's typesystem, can express everything that Java expressions can do and adds even more features like type inference, operator overloading, lambda expressions etc.

The default way of using Xbase is to define a transformation from your language to a structural Java model and embed the expressions in the appropriate Java contexts. A generic code generator builds Java code from this model, so no need to build your own. As we generate plain Java code, these Xbase languages integrate seamlessly with hand-written Java code and work for platforms that are sensitive to bytecode manipulation, like Android.

Java DSLs are the way to go for languages that compile to Java and need rich behavior or expressions. These are probably much more than you'd probably expect. Have a look at our seven languages for some examples. There is also an interpreter for Xbase allowing to skip the compilation step on the language user's side.

We have only implemented an execution environment for Java, so it's up to you if you need another. Restricting the available expressions is easy and could help here significantly. You can also add new expressions to the expression language, but the syntactic space is already quite crowded.

Non-technical users are usually ruled out here. You don't want to teach them managers about closures, do you? You still have complete syntactical freedom for your language. But you still have to regenerate the plug-ins and redeploy them on grammar changes as before.

Internal DSLs (Xtend)

Just because Java doesn't offer the means of abstraction you need doesn't mean you have to define a new language yourself. We have created Xtend, a general purpose language (GPL) based on Java but adding a lot of fancy stuff like type inference, operator overloading, lambda expressions, etc. You guessed it: Xtend is based on the Xbase expression library, but also defines the structural parts (types, fields, methods, annotations etc.), adds extension methods, multi-dispatch methods, template expressions, and offers an even better IDE.

This is already a mighty toolset and can bring you pretty close to internal DSLs in other languages. Look at our examples from EclipseCon 2012 (especially the SWT, Distances and HTML Builder examples).

One additional leap ahead are Active Annotations (new in 2.4, beta). These annotations allow you to participate in the Xtend to Java compilation. They are particularly useful for implementing patterns,  but can be surprisingly powerful in other scenarios, too. Have a look at a few cool examples: Observer pattern, Vistors, JSON classes, a simple REST API, micro benchmarking...

Having everything you need in the language itself gives you short turnarounds as no more regeneration and redeployment is needed. The toolstack stays nicely low. But you're restricted to generating Java and use the syntactical elements of the Xtend language. I would never recommend Xtend to non-programmers, but to everyone fighting with Java.

Xtext tip: How do I get the Guice Injector of my language?

This post is about one of the most frequent mistakes people are making when starting to use Xtext beyond the basic functionality. I stumble across this in our newsgroup about three times a week.

The problem usually starts by the necessity to load a file in your language in the UI, lets say in a custom action. You already know that in Xtext everything is wired up with dependency injection (DI), and that you need a DI configured XtextResourceSet to load a model. So you start looking for an Injector to create your XtextResourceSet and find that one is returned by the generated [DSL]StandaloneSetup.createInjectorAndDoEMFRegistration(). This seems to work fine first, but in the followoing you'll get a lot of strange errors. Things that worked before are suddenly broken.

A variant of the error – more popular among former oAW users – is to run a generator MWE2 workflow containing such a [DSL]StandaloneSetup from the UI.

Never ever use the [DSL]StandaloneSetup for your language within Eclipse!

Why not? Xtext relies on EMF and EMF uses on a bunch of global registries to work. E.g. the EPackage.Registry for the implementation classes for EPackages or the Resource.Factory.Registry for parsers for model files. These are global singletons, and they are usually populated by means of Eclipse extension points, e.g. org.eclipse.emf.ecore.generated_package or org.eclipse.emf.ecore.extension_parser. If you run a standalone Java application – the term standalone means without equinox here – there is no concept of extension points. That means you have to register the DSL to EMF's registries yourself. This is what the [DSL]StandaloneSetup is meant for. If you're using it within Eclipse, you'll overwrite the contributions from the extension points with new instances from the standalone setup. This will crash your application. 

It gets even worse: Xtext has a couple of singletons, too, but they are not global but scoped within the (singleton) Injector of your language. If you just create a new Injector, you'll end up with two instances for all of these singletons. This will likely hit you badly.

Finally, some Xtext components have different implementations for Eclipse and for standalone mode. E.g., Xtext's Java reflection layer (aka JVM model) uses JDT's Java model in Eclipse and Java Reflection in standalone mode. The Injector from the standalone setup will register different implementation classes, thus also breaking functionality.

So how do I use dependency injection in Eclipse properly then?

The Equinox aware Injector you're looking for can be obtained from the Activator of your language (in the UI plug-in). But it would be bad advise to just tell you to go there. You should rather use DI properly. If you think about where to get the Injector you're most often already on the wrong track.

A central aspect of DI is not to care about object creation at all, but just declare dependencies (via @Inject in Guice). Every dependency that is injected will also be created by the Injector so its own dependencies will be created on-demand and injected recursively. As a result, in a well-designed application using DI, there is only one entry class that is explicitly created or populated by the Injector and the rest is automatically DI aware as it is injected somewhere.

IDE components in Eclipse are usually registered by contributing to an extension point with an executable extension, usually an attribute with name class, for example

   <extension point="org.eclipse.ui.editorActions">
      
      <editorContribution targetID="..." id="...">

         <action
 class="[some class extending IActionDelegate]"
  
   ... 

Xtext generates a so called executable extension factory for you that will instantiate the given class using the Injector, so use

  ... class="[DSL]ExecutableExtensionFactory:[some class name]"

and the class will be generated with all its dependencies injected. This is also covered in the documentation.

If there is no such extension point, and your class is not yet instantiated using DI, you might have to access the Injector via the Activator and use it to inject all dependencies, i.e.

   [DSL]Activator.getInstance().getInjector("").injectMembers(this);

Note that you should only have to do this for the entry class, from which all other components are injected. If you have to use the Injector, make sure it is only once.

How do I use DI in tests?

There is a whole section on using DI in tests in the documentation. I am not going to repeat this here. The base configuration requires using JUnit4 and is automatically generated for your language has been created with a recent version of Xtext. If not, make sure to add

   pathTestProject = "[DSL].tests" 

in the section on paths in your MWE2 workflow and

   // generates junit test support classes into Generator#pathTestProject
   fragment = junit.Junit4Fragment {} 

to the fragments and regenerate. This will create the preconfigured test plug-in. Use the InjectorProvider for standalone tests and the UiInjectorProvider for plug-in tests. Once again, your code should not show any references to an Injector.

And the Injector of another language?

Sometimes, you want to switch to a service implementation from another language, e.g. when your DSL allows cross references to another. Usually, you are in the DI context of one language and have an URI to a resource or element of the other language at hand. In this case use the IResourceServiceProvider.Registry:

   @Inject IResourceServiceProvider.Registry reg;

and use that to get the component, e.g. to get the default ILabelProvider

   ILabelProvider otherLangLabelProvider = 
      reg.getResourceServiceProvider(otherLangURI)
           .get(ILabelProvider.class);

Seven Languages By Seven Geeks

One of the most powerful new features of Xtext is the capability to build languages for the JVM. In my opinion, these languages are a real breakthrough in domain-specific language design:

• These DSLs directly interoperate with Java. They compile to Java code and allow to refer to Java artifacts.
• They not only cover structural aspects but also behavior. DSLs become really powerful with a rich expression language offering today what Java has been missing for years, like type inference, lambda expressions, extension methods etc.
• Complicated integration patterns like Generation Gap or Protected Regions become obsolete. Everything can be expressed on the same level of abstraction
• They offer top-notch Eclipse-based tooling and integrate into the Java IDE. Switch between the DSL and the Java code during debugging, refactor across multiple languages, navigate to source etc.

Yet we have the impression that the concept and the benefits of JVM DSLs have not been well understood and adopted. This is why we decided it was time for another example and documentation offensive. The result is the 7 Languages project: Seven example JVM languages highlighting the benefits of this approach in various use cases of Java development:

1. A scripting language. Write code without any boilerplate.
2. A build language similar to Gradle but statically typed.
3. JavaBeans facades for mongoDB objects.
4. A DSL to define Guice modules.
5. A language to route HTTP requests with conditions, variables and dependency injection.
6. A template language
7. A LOGO-like turtle drawing environment.

Clone or fork the code from github and enjoy the documentation on theXtext website.

Multitouch Gestures in the Generic Graph View

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

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.

Rename Refactoring in Xtext 2.0

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

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?

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.

Xtext: Webinar and Eclipse Demo Camp

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

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?

1. Start the wizard by choosing New -> Xtext -> Xtext Project From Existing Ecore Models.
2. Select the EMF generator models¹ from your workspace for which you want a textual syntax and choose your root element's type.
3. Fill in all the language metadata on the second page of the wizard. Remember the file extension.
4. Click Finish and wait until Xtext has generated the two common Xtext plug-ins and the Xtext grammar for your language.
5. Run the MWE2 workflow located in the same directory as the grammar. Now Xtext generates the language infrastructure (parser, editor, formatter etc) .
6. 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.

Eclipse Summit Europe 2009 retrospective

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.

Xtext in Essen aftermath

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

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

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

• http://bugs.eclipse.org/bugs/show_bug.cgi?id=281014
  
• http://bugs.eclipse.org/bugs/show_bug.cgi?id=284850
  

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

Slides from Xtext Workshop at Code Generation 2009

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.

Talks at JAX Conference in Germany

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 Success Story

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 :-)