This is a post about scoping and how to use the EMF index for that. It is in some sense a practical follow up on another blog post about the general idea behind indexing and scoping in Xtext. The topic is somewhat advanced and bleeding edge. This post describes the needed steps to get the current index based default scoping up and running. I've prepared a small screencast demonstrating the result in action. The example language can be downloaded from here.




Today, the common way to do cross resource references in Xtext is to do it via resource URIs. That is if you want to reference a model element (EObject) from another resource, you typically put the whole resource on the scope by adding a corresponding import. Example:

import "platform:/resource/my.project/src/othermodel.dsl"

//.. refer to elements from othermodel.dsl

The corresponding default scoping is very simplistic. Every object in the current resource and in the referenced resources can be referenced by its simple name (as long as it has a 'name').

Although this is very easy to understand, it has it's limitation when it comes to more sophisticated design. If you for instance want to hide some elements or have duplicate simple names in different packages (this can be the case if you use elements, which are developed by others).

In many programming languages we have the notion of namespaces, which are much more flexible and powerful. Java, for instance, is file system agnostic. Although it forces you to put the files into folders which correspond the packages, it ultimately is just based on namespaces (packages, types).
That said Java's namespace mechanism is also a bit limited. For instance I cannot have imports in nested namespaces but only per file. And I cannot nest packages but only classes and interfaces.

Scala and C# both allow to have multiple nested packages within one file and you can put imports per namespace, so that imported names are only visible within that namespace.

In order to demonstrate how to use the index together with Xtext, I've implemented a DefaultIndexBasedScopeProvider which implements a similar semantic. There's a small example I've prepared, where you can see how it can be used. It is mainly a matter of configuring the different implementations with Guice. Programming is not needed as long as you're happy with the defaults.

Here's how it works

The index registeres a builder, which is invoked on resource changes. In order to make your model elements visible, you'll have to contribute a so called Indexer using an extension point.

<extension point="org.eclipse.emf.index.indexer">
<indexer class="org.eclipse.xtext.example.DomainmodelExecutableExtensionFactory
                  :org.eclipse.xtext.index.DefaultDeclarativeResourceIndexer"
            fileextensions="dmodel"/>
</extension>

Please ignore the ExecutableExtensionFactory, which is declared in order to make any executable extension Guice aware, that is you can use dependency injection. This is a different topic and might be covered by another blog post.

The actual class to be instantiated is the one after the colon (':'): The DefaultDeclarativeResourceIndexer, which delegates to an instance of IQualifiedNameProvider, which itself is injected. This means that its implementation can be arbitrarily changed.
The contract of a name provider is very simple: it computes a qualified name for an element, if it returns null, the element is not indexed and hence not referable.

By default we use a DefaultDeclarativeQualifiedNameProvider, which if not otherwise specified looks up a simple name (if there's an attribute 'name') and concatenates it to the qualified name of its parent. It's named 'declarative' because you're able to change the described default behavior per type by just adding a method like this:

String qualifiedName(MyType foo) {
  // compute different qualified name for MyTypes
  // ...
}

It will automatically dispatch to this method as soon as it has to compute a qualified name for an instance of MyType.

With this in place we'll have our elements automatically indexed as long as they are in a project, which have the index nature enabled. Being indexed means that they are globally visible by their qualified name, which is comparable to how public Java elements are globally visible as soon as they are on the classpath.

What's next?

In order to use the index and have it injected into your components (e.g. your scope provider) you'll have to configure the singleton instance from the index bundle into your Guice module. In the example the corresponding binding goes into the UI module and looks like this:

public IndexStore bindIndexStore() {
 return EmfIndexUIPlugin.getDefault().getIndexStore();
}

With that in place you can inject the index store by just adding a dependency in your code:

@Inject
private IndexStore store;

Guice will automatically put the instance into such declared dependencies.
Now that we have a binding for IndexStore we can add the index based scoping to the runtime module:

public IndexStore bindIndexStore() {
 return new PersistableIndexStore();
}
  
@Override
public Class bindIScopeProvider() {
 return DefaultIndexBasedScopeProvider.class;
}

Note the additional IndexStore binding, which is overridden by the binding we previously added to the UI module, but is needed in order to use this stuff at runtime (i.e. without running within exquinox). So it gets active as soon as you run without UI.

How the DefaultIndexBasedScopeProvider works

The DefaultIndexBasedScopeProvider
- looks up EAttributes with name 'importNamespace'
- and translates the globally unique qualified name into shorter ones using those import statements.

By default qualified names with or without a wildcard at the end are supported. For an import of a qualified name the simple name is made available as we know from e.g. Java, where

import java.util.Set;

makes it possible to refer to 'java.util.Set' by its simple name 'Set'.
Contrary to Java the import is not active for the whole file but only for the namespace it is declared in and its child namespaces. That is why you can write the following in the example DSL:

package foo {
  import bar.Foo
  entity Bar extends Foo {
  }
}

package bar {
  entity Foo {}
}

Of course the declared elements within a package are as well referable by their simple name:

package bar {
  entity Bar extends Foo {}
  entity Foo {}
}

Of course the following would as well be ok:

package bar {
  entity Bar extends bar.Foo {}
  entity Foo {}
}

Disclaimer
All this is in a very early stage. The index is not finished and its architecture is not settled down yet. Also the scope provider implementation might be changed in future (I'm sure it will).
Additionally, there are other things around this which we have to work on before considering this mature.

But as I know that there are a lot of bleeding edge users out there, I wanted to share the current state, so you might find a starting point to play with it. The index is an enabler for more advanced functionality in Xtext and in EMF based development in general. So expect it to become an important part in Eclipse Modeling.

Feedback is highly appreciated and should either go to the newsgroup for Xtext (the scoping part) or to the EMFT newsgroup (the index part), because the index project is a component under EMFT.

This Monday the Eclipse DemoCamp took place in London at Skills Matter. You will find a comprehensive review at InfoQ by Alex Blewitt where you can read about NatTable (Dan Pollitt) and JQantLib/OSGi (Richard Gomes) as well as Xtext. And thanks to Eren Aykin you will find a video podcast of the latter, too!

This time I tried to spread the idea of DSLs with chess and different ways of expressing moves within the game. In the first part of my presentation I processed cryptic notations like “Rd2-c2″ or more natural equivalents such as “rook at d2 moves to c2″ to work with them as true Java objects and eventually visualized chess fields. Second, I tried to emphasize the value of DSLs in today’s software projects where we implemented another DSL live at the DemoCamp in the end. You will find my slides at SlideShare again.

It was quite informative to chat with the Eclipse folks in London afterwards. Most of them have a pragmatic view at modeling and tools in general. I really appreciate this! Thank you, Neil, for organizing this event and inviting via twitter.

Links

• Slides at SlideShare
• Video Podcast at Skills Matter
• Review at InfoQ

Source Code

Loading chess DSL text files as Java objects:

package org.xtext.example.chess;

import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.xtext.resource.XtextResourceSet;
import org.xtext.example.ChessStandaloneSetup;

public class JavaTest {

	public static void main(String[] args) {
		String filename = "some/path/MyModel.chess";
		Game g = getGame(filename);
		System.out.println(g.getWhitePlayer() + " vs. " + g.getBlackPlayer());
		for (Move m : g.getMoves())
			System.out.println(m.getSource() + " to " + m.getDest());
	}

	private static Game getGame(String filename) {
		ChessStandaloneSetup.doSetup();
		ResourceSet rs = new XtextResourceSet();
		Resource res = rs.getResource(URI.createFileURI(filename), true);
		return (Game) res.getContents().get(0);
	}

}

Xtext has been released as a part of the Eclipse Galileo release train on June 24th, 2009. Xtext is a framework for building DLSs (domain specific languages). In fact, it can be seen as a DSL for defining DSLs.

In this article, we will develop a small DSL for defining entities.

Download and Install

Hop over to http://xtext.itemis.com and download an Xtext distribution matching your platform. We've got all major platforms: Windows, Mac OSX Carbon, Mac OSX Cocoa 64, Mac OSX Cocoa 32, Linux Gtk 64, Linux Gtk 32.

To install, unzip the distribution file to a directory of your liking.

Windows users, please make sure you unzip to a directory near to your filesystem root! Eclipse contains files and folders with long names that might be hard to handle for Windows.

Create a new project

After launching Eclipse and creating a new workspace (or using an existing one), create a new Xtext project by selecting File -> New... Project... -> Xtext Project. In this article, we're creating a DSL for describing entities, so let's go with the following settings:

• Main project name: org.xtext.example.entity
• Language name: org.xtext.example.Entity
• DSL-File extension: entity
• Create generator project: yes

Click Finish to let Xtext create the three projects that make up your DSL:

• org.xtext.example.entity - this project contains the DSL itself, including all back end infrastructure like the parser and the meta model.
• org.xtext.example.entity.ui - as the name implies, this project contains all UI centric code of the DSL: the editor, the outline, content assist and so forth
• org.xtext.example.entity.generator - this project contains a code generator which will transform the DSL scripts (aka models) you write in your DSL into something useful. In our example, we will create some POJOs and DAOs from our models.

Upon finishing creating these three projects, Xtext opens a file Entity.xtext, which contains a sample grammar, which we will change in a second.

Define the grammar for your DSL

Next up, we need to define the grammar for our DSL. To make things easier for us, let's first write down a sample model. Please open org.xtext.example.entity.generator/src/model/MyModel.entity and key in the following text:

typedef String
typedef Integer
typedef Date mapsto java.util.Date

entity Person {
  String name
  String surName
  Date birthDay
  Address home
  Address work
}

entity Boss extends Person {
  Person* employees
}

entity Address {
  String street
  String number
  String city
  String ZIP
}

Most of this model should be pretty obvious, but there are two things worth noting:

• We define our own list of data types to gain a certain degree of flexibilty, i.e. to map them to different types in the host language, as can be seen for the Date data type, which gets mapped to java.util.Date (we might also decide to map it to java.sql.Date
• The star (*) denotes multiplicity. We might also have chosen square brackets (Person[] employees) or something completely different - it's largely a matter of taste.

Let's derive the grammar for this model. Open org.xtext.example.entity/src/org/xtext/example/Entity.xtext, erase its entire contents and enter the following:

grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals
generate entity "http://www.xtext.org/example/Entity"

The first line indicates we want the new grammar to be derived from the (built-in) grammar Terminals, which defines some basic terminal rules (like STRING, ID and so forth). If you're interested, CTRL+Click on the language name to navigate to its definition.

The second line defines the name and namespace URI for our own grammar.

Let's now define that our DSL supports types. Add the following lines:

Model:
  (types+=Type)*;

Type:
  TypeDef | Entity;

This tells Xtext that our Model contains any number (i.e. 0..N, as declared by the *) of Types. What exactly a Type is needs to be specified. Apparently, a Type can be either a TypeDef or an Entity:

TypeDef:
  "typedef" name=ID ("mapsto" mappedType=JAVAID)?;

A TypeDef starts with the keyword typedef, followed by an ID making up its name. Following the name, we can optionally (hence the question mark at the end) add a mapsto clause. The fragment mappedType=JAVAID specifies that the TypeDef will later have an attribute named mappedType of type JAVAID. As JAVAID is not yet defined, we need to do so:

JAVAID:
  name=ID("." ID)*;

So, a JAVAID is a sequence of IDs and dots, making up a qualified Java type name, such as java.util.Date.

Next, let's define how to model entities:

Entity:
  "entity" name=ID ("extends" superEntity=[Entity])?
  "{"
    (attributes+=Attribute)*
  "}";

As you might have guessed, Entitys start with the keyword entity, followed by an ID as their name. They may optionally extends another entity. Surrounding a rule call with square brackets means "this is a cross reference", i.e. a reference to an already existing element.

Entitys do have Attributes (any number, to be precise), thus we have to define how Attributes look like:

Attribute:
  type=[Type] (many?="*")? name=ID;

By now, you should be able to read this rule: an Attribute has a type which is a cross reference to a Type (which is either a TypeDef or an Entity), it has an optional multiplicity indicator (the star) and - of course - if has a name.

Your grammar should look like this by now:

grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals

generate entity "http://www.xtext.org/example/Entity"

Model:
  (types+=Type)*;

Type:
  TypeDef | Entity;

TypeDef:
  "typedef" name=ID ("mapsto" mappedType=JAVAID)?;

JAVAID:
  name=ID("." ID)*;

Entity:
  "entity" name=ID ("extends" superEntity=[Entity])?
  "{"
    (attributes+=Attribute)*
  "}";

Attribute:
  type=[Type] (many?="*")? name=ID;

Compiling the DSL

Now it is time to see the fruits of our labor. But first, we need to compile our grammar. Xtext will create:

• a parser
• a serializer

an Ecore meta model

a full blown Eclipse editor

from this grammar. To make this happen, please select org.xtext.example.entity/src/org/xtext/example/GenerateEntity.mwe and select Run As -> MWE Workflow from the context menu. Xtext will now generate the entire infrastructure for your DSL and after a few seconds you should have a shiny new DSL including a great editor.

Taking it for a spin

Seeing is believing, so let's take the DSL editor for a test drive. Select the DSL project org.xtext.example.entity and, from the context menu, select Run As -> Eclipse Application. A second instance of Eclipse will be started.

In this new instance, create a new, empty project (File -> New -> Project... -> General -> Project. Create a new file Sample.entity in the new project.

You can now insert the model we designed above or enter a new model:

Leveraging the model

Now that we've got a fancy editor for our DSL, we want to transform the models we can create with this editor into something meaningful. This, however, will be the topic of the next installment.

More info

Feel free to discuss this article in the comments section of my blog. Should you have any technical questions regarding Xtext, we've got an excellent newsgroup where the committers answer your questions. We also offer professional (commercial) support, i.e. customized trainings to get your team up to speed. Just drop us a note, we're happy to discuss the details with you.

Marking the end of this years series of DemoCamps, Neil Bartlett and SkillsMatter are organizing the final DemoCamp in London on Monday 29th, 2009. Yes, that's next monday!

Neil was kind enough to invite someone from the "modeling/oAW folk", so Heiko Behrens will be giving an Xtext demo.

If you haven't had the chance to attend Code Generation 2009 or if you're curious what all this DSL talk is all about, I urge you to sign up for the DemoCamp now - it is free of charge.

I was fortunate enough to hear Heiko speak at the DemoCamp in Hamburg. Not only is Heiko a very good speaker (with a very convincing, deep voice), but also did he manage to come up with some very good examples of what a DSL is and why you should consider using them in your projects.

By the way, if you want to play around with Xtext before the DemoCamp, you can get a fresh copy from our download site at http://xtext.itemis.com.

Today is the day. The framework we've been working on for over a year has been released.
And before I fall into a big dark hole (because I forgot to think about what is next), I wanted to use this medium in order to thank my team. I never ever had the pleasure to work with such nice and talented people. Without them there would be nothing to release.

Usually I prefer to stick talking about the team as a whole as opposed to talking about the individuals, because the synergy is so important and needs to be emphasized. But on the other hand it's important for me that everybody knows who was involved and made this possible.
So I will make an exception this time and want thank them in alphabetical order:


Heiko (Behrens), our drummer, came in one year ago. The first thing he did was developing the Ecore model generation from Xtext grammars. He's an excellent software developer and at the same time (and that is rare) a highly skilled communicator and team player. He developed a profiler for Xpand and improved the performance of the static analysis of Xpand templates about 300%. Also he designed and implemented our nice new website.
Thank you, Heiko. I have learned a lot from you.

Michael (Clay) is one of the few people who were already active contributors to the previous version of Xtext. He worked a lot on the code completion functionality as well as implemented a textual format for Ecore models as one of the examples. I'm sorry that especially in the beginning, I was not able to integrate him enough, since we had a lot of offline discussions, which he couldn't join. Thank you for contributing (and for your patience).

Moritz (Eysholdt) joined our team in April 2008 in order to write his master thesis on co-evolution of meta models and models (he finished with 100 out of 100 points). In parallel he not only managed the support for the XSD adapter he wrote for Xpand, but wrote the serialization algorithm for Xtext. That is definitely not an easy one and he solved it without too much worry. Good to have you!

Peter (Friese), our tweeting bird, always has an eye on how the project is viewed from outside. He is not only one of the kindest people I know but is so active in the Eclipse Community, that some people even have thought that he was the founder of itemis. Thank you, for doing all that community work and spreading the word. Also thank you for coming up with the WikiText infrastructure, which we used to write the documentation.

I've been working with Dennis (Huebner) for about 6 years now. He's always been a great person to work with. Last year we had serious problems with our build infrastructure. Every now and then strange errors came up and we didn't know what to do. So at some point Dennis took this thing over and managed it. It was great to see how he cared about the whole project, he fixed broken builds even at night or at the weekends. Without him there would be no release today.

Jan (Koehnlein) joined the team in February, 2008. Among all the cool stuff he did, the most noteworthy things may be co-authoring the initial design of the grammar language as well as implementing the partial parsing algorithm. Also he's the most experienced with EMF. Jan has really become a friend of mine over the past year and I especially enjoyed visiting all the conferences with him. But, Jan, please do not talk me into drinking whisky again. Thanks!

Patrick (Schoenbach) is the good fairy behind the scenes. He's responsible at any day time and when ever there was something wich needed urgent action, Patrick was there. Thank you, Patrick, I hope we can meet some day.

Knut (Wannheden) joined the team very late, but had provided a lot of useful features before. Knut is one of these seldom seen developers who look deep into the code and understands what's going on in an incredible short amount of time. Whatever he contributes is of highest quality. Good to have you.

Sebastian (Zarnekow). He is unbelievable. He joined the team late 2008. If you look at the commit statistics, you'll see what kind of productivity gain Sebastian brought to the project. From day one he cared about every single line, he reviewed every bit which was committed. On the other hand he contributed masses of code, which is between the best I've seen so far. Sebastian is propably the one with the most knowledge about the whole system and has become something like a co-lead to me. Besides other things he tought me to improve keeping discipline (still learning ;-)) and why it is important. Sebastian, you made my year.

We've just been out for lunch where I got the chance to take this nice photo (Note the name of that restaurant!). Hopefully we can convince someone to open a new restaurant or rename an existent to 'Helios' soon.

Have fun (while downloading the complete Xtext distro from http://xtext.itemis.com/)!

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
  

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.

It has been online for a couple of days and also been mentioned on twitter as well as in the blogosphere. But we haven't announced it "officially" yet. So here we go:

We have a new website :-)



I think Heiko really did an excellent job. Given the limited time he had (as it states in the screenshot there are only five days left...) the result is just fantastic.

How do you like it?

This year's Code Generation Conference in Cambridge UK is again a great event. So far I listened to a lot of interesting and entertaining talks and had many discussions on code generation and language development. It's organization is just perfect. They even came up with great weather and fireworks (each night!)!


Thanks to Mark Dalgarno and his team, who again did an excellent job.

I've uploaded the slides of the presentation I did together with Sebastian on Tuesday.

Today is the last day, and there'll be a workshop on a new technology called Xtext.
Sounds exciting ;-)

On Monday, Sven, Sebastian, Moritz, Jan and me traveled to Cambridge where the Code Generation Conference takes place each year. Arriving one day ahead we had enough time to acclimate with fish ‘n chips and some ale at the local pubs before polishing our presentations.

The first conference day on Tuesday…

…started with a smooth introduction on modeling, DSLs and all the other terms specific to our focal point. It’s always interesting to see how other experts try to explain what we are doing and Juha-Pekka Tolvanen (MetaCase) did a great job even though he nearly ignored alternatives to graphical models.

Second, Sven and Sebastian talked about challenges in textual DSL design and concentrated on topics such as reusing languages and using models beyond the description of structures. If you follow their blogs you will certainly find out what they are interested in. This was the second time I noticed that the audience here at #CG2009 acts a bit more open-minded towards UML models and my coworkers sometimes had to play hardball with questioners.

Karsten and me skipped the next time slot to prepare ourselves for our own talk “Mastering Differentiated MDSD Requirements at Deutsche Boerse AG” we gave at the end of the day. We packed a lot material into 75 minutes but still managed to come up with a short demo that shows how Xtext can interact with graphical models. You can download the slides at slideshare but the demo is not yet ready, sorry (the attendees asked for this, please drop me a mail or comment on this post so I can inform you later on).

After a stressful day, the organized punting trip along the Cam made this day perfect to me.

Wednesday…

…was a completely different story to me. Instead of listening to or presenting well-known ideas I had the opportunity to get some deep insights of concepts I only read about before. After an amusing staged fight between Markus Völter (textual modeling) and Steven Kelly (graphical modeling) my day started with the well-prepared hands-on session about MetaEdit+ Juha-Pekka Tolvanen, Risto Pohjonen and Steven Kelly gave. From what I have seen I would say that this software is the most sophisticated graphical modeling tool at the market today.

The session I have joined afterwards was not that impressive but I compensated for this with today’s highlight: Language Definition, Extension and Composition with MPS. Markus Völter and Konstantin Solomatov complemented one another and impressed the audience deeply with the upcoming version of MPS. This was the first time I have seen a live presentation on this little pearl of modeling.

Some lightning sessions about Fit4oaw, MBase, UMLCanvas and GWT made the end of the technical part. A nice dinner with french impressions made the night a big success again.

I want to thank Mark Dalgarno and Andy Moorly for organizing this event. Questions about the room plan, the need for a different stage setup, giving up their seat at the dinner or ad hoc money exchange for thirsty attendees - no problems for them. Your upfront organization as well as your courteous appearance is simply overwhelming!

Update: This post has been published at The Model Driven Software Network, too.

Links

• Slides of the session at slideshare
• Pictures of the conference at flickr
• Twitter tweeds about the conference

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?

I recently came across some DSLs which had some defects. Let's look at a sample I quickly hacked together with Xtext:

Here are two recommendations I'd like to give when designing a textual DSL:

1. Don't use uppercase letters in the keywords of your DSL, unless you either really like them. In the sample DSL, the keywords (Element, EndElement, Child, Endchild all start with an uppercase letter, which makes it cumbersome to edit the DSL script (you need to press the shift key a lot). Back in the days when we didn't have syntax highlighting, UPPERCASE keywords made a lot of sense as they helped to draw a better distinction between the keywords, the variables and the constants (strings and numbers) of a program. Nowadays, it is hard to find an IDE which does not offer syntax highlighting, so this argument does not hold any more.
2. Do not use noisy begin...end syntax constructions. They do not increase readability of your DSL script and they add to the amount of code to be typed.

Here is an improved version of the DSL script:

By removing the Endelement and Endchild keywords, we have improved readability a lot. Using lowercase keywords has lowered the effort you need to invest to key in the DSL script. And - honestly - don't we all like to be lazy at times? After all, one of the goals of DSLs is to make your work easier and more efficient.

That being said, have a great weekend!

By the way, if you need help designing a DSL with Xtext - I and the entire Xtext team are happy to assist you. Just drop me a line (peter at itemis dot com) or hop on to our professional support site

With the Galileo Release coming up, you might find yourself having a hard time updating to the latest milestones AND keeping your favorite plug-ins up-to-date.

Did you know that you can migrate your additional plug-ins from one Eclipse install to another one? This can be a huge time-saver, especially for people who like to live on the bleeding edge.

Here's how:

1. Install a fresh copy of Eclipse. Let's assume you install Eclipse 3.5 RC4 Cocoa 64bit (you're feeling lucky)
2. Let's further assume you've got an existing install of Eclipse 3.5 RC3 Cocoa 32bit with some additional plug-ins, like FindBugs, WindowBuilder Pro, etc.
3. After installing, start your newly installed instance of Eclipse
4. Select Help -> Install New Software...
5. In the Install dialog, click the Add... button to add a new update site:
   

6. In the next dialog, click on Local... to add a local update site:
   

7. using the file chooser, browse to <path_to_your_OLD_eclipse_instance>/eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/ and click Choose to select that directory.
8. Click OK to add the update site:
   

9. The Install dialog will now list all plug-ins installed in the old location (i.e. your old Eclipse instance), clearly highlighting the ones that are not already installed in the new instance:
   

10. Check all features that you want to transport to the new location and continue the installation by clicking Next>.
11. After confirming the license terms and clicking Finish, Eclipse will install the selected features from the old location into the new location. After the obligatory workbench restart you're good to go.

The only thing that I am wondering about is: why is there no first-class UI action (e.g. an import wizard) to do this?

Reading tweets, newsgroup posts, blogs, articles or press releases I am very excited to notice that xText gains increasing attention. As far as I can see most newcomers learn about xtext as a great tool to create domain specific languages (DSLs). Also, X-Text seems to fulfill a need many software engineers feel: Inventing their own programming language.

People are just starting to explore the possibilities and sometimes it is difficult for them to find the right word to name a concept or share an idea. We do our best to support those seekers and are glad to do away with a common uncertainness: The right spelling is “Xtext” and from today its logo does reflect this.

Beside every other wrong spelling “xtext” was the most prominent. It took us a while to find out why this was the case. Eventually, we realized that the omnipresent logo started with a lower-case “x” (convince yourself). So it was our own fault!

With the help of Carsten Oltmann we are proud to present the new version of the Xtext logo. Feel free to place it into your presentations, on your blogs or as a sticker at your laptop.

Downloads

I will provide the logo in four different flavours and in two different formats. You can download a vector graphic and a PNG in suitable sizes. The background color of the thumbnails are for reference only, the provided graphics are transparent.

EPS (vector)	EPS (vector)	EPS (vector)	EPS (vector)
PNG (800px)	PNG (800px)	PNG (800px)	PNG (800px)
PNG (300px)	PNG (300px)	PNG (300px)	PNG (300px)
PNG (100px)	PNG (100px)	PNG (100px)	PNG (100px)

Only two weeks until the release of Xtext 0.7.0 (simultaneous with Galileo). If you've been using the Xtext version previously shipped with openArchitectureWare (oAW Xtext) you might wonder what has changed and how to migrate to the new version from TMF.

We now have a migration document describing the most important decisions, changes, and the motivation behind them. We hope it will not only help oAW Xtext users to get their projects migrated but also provide them a good start for learning about the new ideas and concepts. Any feedback is highly appreciated!

We are confident that migrating to TMF Xtext is a good idea and pays off soon. Your DSLs will not only run on faster and better code (we e.g. have lots of unit tests), but you'll automatically benefit from cool new features like serialization, pretty printing, template proposals, and semantic highlighting (just to name a few).

Also we, the committers, love the project and are keen on helping you in the newsgroup :-).
Note, that itemis offers migration services and trainings, just in case you're busy or don't want to do it yourself. Just drop me a note in that case.

Whether it was just pure coincidence or destiny - yesterdays DemoCamp in Hamburg happened to fall on the same day as Towel Day.

Although we had quite a bunch of attendees (I counted 40), only one brought his Towel.

Thanks to our speakers, Martin and I were able to put together a really exciting program:

1. Moritz Eysholdt, Patching Models and Evolving Meta Models
2. Heiko Behrens, TMF Xtext
3. Simon Zambrovski, Common Navigator Framework
4. Marco Mosconi, Modular EMF/GMF customization with ObjectTeams/Java
5. Markus Alexander Kuppe, Distributed OSGi (RFC 119) - The ECF way

Moritz presented the result of his master's thesis on the topic of metamodel evolution and explained how models can evolve together with their metamodels. This might also be of interest for data modeling.

Heiko delivered a great presentation on the upcoming version of Xtext. He used a well-known example that everybody could relate to (no, not entities and services!) so it was really easy to understand how domain specific languages work and how Xtext can help to implement a domain specific tool chain.

Simon presented on the Common Navigator Framework - a powerful framework which helps you to assemble tree views in a mostly declarative manner. Simon was bold enough to do a live coding session, but the demo gods didn't smile on him, so he showed us the prepared solution, which was still very convincing. Simon prepared an article about the CNF on his blog, so if you're interested, drop by - it's worth a read.

After the break, Marco Mosconi showed how ObjectTeams/Java can be used to non-invasively customize generated code. As a real-world example he used the UML diagrams from the Eclipse UML2Tools project. The UML2Tools project uses GMF to generate the diagram code based on the UML2 metamodel (implemented as an ECore model). A rather large number of generated artifacts have to be customized to make sure the diagrams behave correctly. Marco showed how this is especially required for associations (I find it kind of funny how everybody uses associations to explain how complicated the UML metamodel is). The UML2Tools class diagram has been customized in at least 200 different locations, so you get a big maintenance problem (generated and non-generated code are mingled). With ObjectTeams, it is possible to extract all customization code into so called teams which then are able to enhance the generated code in an aspect oriented way. In a way, ObjectTeams is like AOP on steroids.

The official part of the DemoCamp was concluded by a talk held by Markus Kuppe on Distributed OSGi. Markus briefly explained the architecture behind Distributed OSGi and gave a demo of an Eclipse RCP application that communicated with an iPhone (which ran an Equinox server). Markus used the Eclipse Communication Framework (ECF) to achieve this - ECF contains a provider for Distributed OSGi.

Eclipse DemoCamps are social events and aim at creating room for discussion and interaction. So, after the official part of the DemoCamp, we headed down to the EAST Bar to have some nice chats over some frosty beverages (I definitely recommend "Cool Mango").

Feedback has been very positive so far and I surely hope everybody enjoyed the DemoCamp as much as I did. Thanks to the Eclipse Foundation, it-agile and itemis for making this event possible by sponsoring the location and the drinks!

If you feel you missed out, drop me or Martin a mail so we can invite you the next time around.

Yesterday’s Eclipse DemoCamp in Hamburg was a successful social event. The organizers Peter and Martin scheduled the Eclipse Stammtisch directly after the demo sessions so that many known but (to me) even more unknown faces gathered together to discuss the impressions at the bar.

Beside the talks from Moritz Eysholdt (Patching Models and Evolving Meta Models), Simon Zambrovski (Playing with Eclipse Common Navigator Framework) and Markus Alexander Kuppe (Distributed OSGi, RFC 119 - The ECF way) there was a talk about ObjectTeams again. Marco Mosconi demonstrated how one can weave manually written code into generated GMF editors with an aspect-oriented approach. Nice!

I had the opportunity to talk about Xtext in front of an audience that mostly had not seen it before. Playing with expectations and trying out some new ideas was great fun. Xtext becomes more stable and doing live presentations is no risk but a pleasure.

For those who do not want to miss the pizza recipe nor the class schedule DSL, you will find attached the slides. Peter’s photos and Simon’s album give a visual impression of the event. Also, please note that we have just published ready-to-use distributions with the current Xtext RC2 release. Nothing should stop you from implementing your very own grammar. And if you come up with a textual DSL to avoid wrong IDs in your plugin.xml, let me know

Downloads

• Slides at SlideShare (German)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (Linux-gtk)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (MacOS X-carbon)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (MacOS X-cocoa)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (Win32)

Last week, Heiko, Jan and I were talking about blogging about the tools that make our lifes easier on the Mac. "Isn't the Mac supposed to be making your life easier anyway?" you might ask. Well, most things really are easy with a Mac. However, there are some things that cannot be done easily with a Mac. More often than not, this is due to the fact that Apple tries to hide the complexity of computers from nosy users. Which is fine for beginners - but makes life harder for the pros. Thankfully, there is a vast array of tools out there that fill the gap and make life on a Mac easier.

I am going to try to post one tool recommendation per week - unless I am on vacation or speaking at a conference.

So without further ado, here is the first tool: Skitch!

Skitch is a tool that helps you to create screenshots. I need to create lots of screenshots: for documentation, to explain things to people by mail, and to annotate my bug reports. Of course, Mac OSX has several shortcuts to create screenshots, so what's the deal about Skitch?

First of all, Skitch allows you to view and edit your screenshot: press CMD+SHIFT+5, select the capture area and voilà - Skitch opens a window showing the screenshot just taken:

You can now use the tools at the left hand side of the Skitch window to highlight certain areas of the screenshot, which comes on handy if you're filing a bug report for your favorite open source tool.

When you're done with editing, you can either drag the image to another application (using the "drag me" tab at the bottom of the window) or you can post the image to the web. I have set up Skitch to use my Flickr account, so I can use the images in other tools right away (I am writing my blog posts in Mars Edit, which has a great Flickr integration, so I've got a complete tool chain here). Skitch supports a number of file formats (JPG, SVG, PDF, TIF, GIF, BMP and native Skitch), so you can select the desired file format before sending the image to the web or dragging it to another application.

All images are also stored in a local history, so if you need to go back to one of the screenshots you took a while ago, no problem with Skitch.

Skitch really has made my life on my Mac easier because it integrates with other tools (both online and offline) so well and because it eliminates many steps that made dealign with screenshots so cumbersome before.

You can download Skitch beta from http://www.skitch.com. You will be asked to sign up, however, both the download and the software will work without registering.

Happy screen shooting

The Hybridlabs beautifier has become a famous component for oAW. It is a Java code formatter based on the Jalopy library and what it makes it especially interesting is its feature of auto-organizing Java imports. Since M2T is now upcoming users ask for porting the component to M2T Xpand. I have asked Karsten Klein, the founder [...]