Getting started with Xtext, part 2
Last week, I showed you how easy it is to create a DSL with Xtext. In this installment, we will have a look at how to leverage the models created with the DSL.
Goal
Let's imagine we want to create an application for orders. People can sign in to the system, place orders for various items, check out and have them sent to their address. Very simple, but we can show a lot of things here.
As we expect to be writing more than one application of this type and as we also would like to be able to express the structure of the application on a business level (one of the major drivers for DSLs and MDSD for that matter), we come up with the idea of using a DSL to describe what the application does. Defining the DSL is what we did last week. This week, we need to map the concepts of the DSL to some code and some APIs we're going to program against.
Read more
Getting Started with Xtext
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.
Read more
Xtext does London
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.
Noisy DSLs
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:
- 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.
- 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
Following Eclipse Milestones
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:
- Install a fresh copy of Eclipse. Let's assume you install Eclipse 3.5 RC4 Cocoa 64bit (you're feeling lucky)
- 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.
- After installing, start your newly installed instance of Eclipse
- Select Help -> Install New Software...
- In the Install dialog, click the Add... button to add a new update site:

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

- 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.
- Click OK to add the update site:

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

- Check all features that you want to transport to the new location and continue the installation by clicking Next>.
- 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?
Towels, Models and Bundles: Eclipse DemoCamp in Hamburg
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:
- Moritz Eysholdt, Patching Models and Evolving Meta Models
- Heiko Behrens, TMF Xtext
- Simon Zambrovski, Common Navigator Framework
- Marco Mosconi, Modular EMF/GMF customization with ObjectTeams/Java
- 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.
Mac in Black: Taking Screenshots with Skitch
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
Advanced WikiText
In my recent posting, I showed you how to use Mylyn WikiText to easily create documentation for your project.
In this installment, we're going to look at four things:
- How to create PDFs
- How to automate your publishing process
- How to split your documents to facilitate team work
- How to use DocBook as an intermediary format to add even more flexibility to your publishing process
Lots of stuff, so let's get started!
How to create PDFs
The WikiText documentation states you can create DocBook, HTML and Eclipse Help from Wiki markup. So, how to create PDFs? Well, there are many ways to create PDFs. If you just want to create PDFs inside the IDE, you can download the Textile-J PDF add-on for WikiText. Textile-J is the predecessor of WikiText. The reason why the PDF output is not included in WikiText is that some of the required frameworks need to transform to PDF are not yet IP-approved (see bug 258349 for more information).
To install the Textile-J PDF add-on, proceed as follows:
- Make sure you have WikiText 1.1.0 or better installed
- Add the Textile-J update site to your Update Manager: https://textile-j.dev.java.net/builds/wikitext/site
- Refresh the Update Manager. You should now see Textile-J WikiText PDF in the list of available features.
- Select Textile-J WikiText PDF and click Install
- Restart Eclipse as requested
You can now right-click on any wiki file (*.textile, *.mediawiki, *.confluence, *.twiki, *.tracwiki and select Textile-J -> Generate PDF from the context menu.
How to automate the process
If you want to create PDFs outside the IDE (e.g. on your CI server using ANT), you need to create a build file:
<project name="how-to-use-wikitext" default="wikitext2pdf" basedir=".">
<property name="wikitext.standalone" value="lib"/><!-- path to wikitext standalone package -->
<path id="wikitext.classpath">
<fileset dir="${wikitext.standalone}">
<include name="org.eclipse.mylyn.wikitext.*core*.jar"/>
<include name="net.java.dev.textilej.wikitext.*core*.jar"/>
<include name="net.java.dev.textilej.wikitext.*lib*.jar"/>
</fileset>
</path>
<taskdef classpathref="wikitext.classpath"
resource="org/eclipse/mylyn/wikitext/core/util/anttask/tasks.properties" />
<taskdef classpathref="wikitext.classpath"
resource="net/java/dev/textilej/wikitext/pdf/core/util/anttask/tasks.properties" />
<target name="wikitext2pdf" description="Generate PDF from textile">
<wikitext-to-pdf markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-pdf>
</target>
</project>
By the way, there are ANT tasks for all other output formats as well, so you can automate the creation of Eclipse Help, HTML and DocBook, too:
<wikitext-to-docbook markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-docbook>
How to split your documents to facilitate team work
Now that you know how to transform Wiki markup to various output formats, you might wonder how to split your Wiki files into smaller chunks so the members of your team can work on them separately. This is something which is very easy with, say, LaTeX or DocBook because they both have the concept of importing other documents. In Wikis, there usually is no such thing as importing another Wiki page - you rather link to that other page. If you're writing a documentation, this isn't sufficient, however. You really need to be able to import document fragments.
Instead of adding the notion of imports to WikiText, I decided to control the assembling of the master document by using a little bit of ANT wizardry and a text file.
The text file (named index.txt controls the order in which the document fragments ned to be glued together:
introduction.textile grammar_language.textile newnoteworthy.textile
The build.xml now needs to be enhanced so that it reads the control file and use this information to assemble the Wiki files in the order requested:
<target name="assemble">
<loadfile srcfile="doc/index.txt" property="inputfiles">
<filterchain>
<tokenfilter>
<replacestring from="\n" to=","/>
</tokenfilter>
</filterchain>
</loadfile>
<concat destfile="documentation.textile" append="false" fixlastline="yes">
<filelist dir="doc" files="${inputfiles}"/>
</concat>
</target>
So what happens here is that we read in the contents of the index.txt file, concatenate all file names, separated with a comma to one large line and feed that large line into the concatenate task that will then concatenate the contents of all those files in the given order so we get one big file.
After that, the big file can now be processed as usual:
<target name="generate-pdf" depends="assemble" description="Generate PDF from textile">
<wikitext-to-pdf markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-pdf>
</target>
How to use DocBook to gain more flexibility
DocBook has been around for quite some years now and together with LaTeX still will give you the most flexibility when it comes to documentation engineering. I have been using both LaTeX and DocBook to write all sorts of documentation, ranging from my diploma thesis to open source project documentation and have found both the be versatile and reliable, but also quite verbose. Regarding flexibility, both give you the possibility to choose a document template / style of your liking. If none of the existing document styles match your needs, you can more or less easily create you own.
As WikiText supports creating DocBook from your Wiki files, we'll have a look at how to use this DocBook output to further process it. Here is what we need to do:
- Enhance our build script so it downloads the relevant DocBook files (libraries, basic styles and XSL transformations)
- Add targets to our build script that allow you to choose the output to be created: PDF, HTML or Eclipse Help
The whole process will look like this:

Let's have a look at some crucial parts of the script.
We already saw how to assemble multiple Wiki files into one big Wiki file. The next step is to convert this file to DocBook:
<target name="wikitext2docbook" depends="assemble" description="Generate DocBook from textile">
<wikitext-to-docbook markupLanguage="Textile">
<fileset dir="${basedir}">
<include name="documentation.textile"/>
</fileset>
</wikitext-to-docbook>
</target>
After that, we need to convert the DocBook file to PDF:
<target name="docbook2pdf">
<echo>Converting article to PDF...</echo>
<delete file="${dest.dir}${file.separator}${documenat.name}.pdf"/>
<delete file="${dest.dir}${file.separator}${documenat.name}.fo"/>
<xslt in="${documenat.name}.xml"
extension="xml"
out="${dest.dir}${file.separator}${documenat.name}.fo"
style="${document.stylesheet}">
<factory name="org.apache.xalan.processor.TransformerFactoryImpl">
<attribute name="http://xml.apache.org/xalan/features/optimize" value="true"/>
</factory>
<xmlcatalog>
<entity
publicId="docbook.xsl"
location="${docbook.dir}${file.separator}fo${file.separator}docbook.xsl"/>
</xmlcatalog>
<param name="generate.toc" expression="book toc" />
<param name="show.comments" expression="0" />
<param name="header.rule" expression="1" />
<param name="admon.graphics.extension" expression=".gif"/>
<param name="admon.textlabel" expression="0"/>
<param name="admon.graphics" expression="1"/>
</xslt>
<docbook2pdf
source="${dest.dir}${file.separator}${documenat.name}.fo"
target="${dest.dir}${file.separator}${documenat.name}.pdf"/>
<delete file="${dest.dir}${file.separator}${documenat.name}.fo" />
</target>
You can now control the output by supplying different stylesheets. DocBook XSLT comes with a variety of stylesheets for articles, books and online help systems. You can now easily create printed documentation AND online help from one source. DocBook XSLT supports EclipseHelp, JavaHelp, HTMLHelp (the Windows Help System) and even man pages!
So, next time you need to write documentation for a project you're working on, don't let it get you down. Instead, set up a trusty WikiText / DocBook toolchain and write down that documentation in Wiki markup in no time!
The whole build script and the sample document are available for download for free. If you need help setting up a tool chain or want to book me for consulting, drop me a line (peter dot friese at itemis dot com).
Many thanks to David Green and Steffen Pingel of WikiText and Mylyn who tirelessly fixed bugs I found, applied patches and created EA builds!
Getting started with WikiText
Documentation is the bane of all developers. Nobody likes to write documentation, but most people know we need it. Even more so in Open Source projects. If you don't have a decent documentation, it will be hard to find contributors which will eventually stall the projects ability to acquire new committers.
While documenting code is discussed quite controversial (see here, here, here and here), most people seem at least to agree that a high level documentation outlining the concepts of the software in question is appropriate.
The options to write high-level documentation are:
- Word processors like Word, OpenOffice, Pages and the like
- LaTeX
- DocBook
- Wikis
Using word processors for writing high-level documentation has serious drawbacks, especially when a whole team needs to contribute to the documentation. Do you remember master documents?
LaTeX is a great alternative, as it allows us to split documentation across several text files - this allows for efficient team work. Moreover, text files just cannot break and can be versioned / merged / diffed quite easily. However, LaTeX syntax is not for the faint of heart.
DocBook is great, too: it uses XML to describe documents and has a great number of transformations to about every output format you could think of (PDF, HTML, EclipseHelp, HTML Help, JavaHelp and even man pages! However, not everybody likes XML and in fact DocBook tends to be a little noisy.
So this leaves us with Wikis. They are great in many regards: you can write your documentation online, most wikis support versioning and diffing to a certain degree and most wikis have a decent collision detection that helps to work on documentation collaboratively. Thanks to offline Wiki editors for IDEs, we can even store wiki documents in local files.
Enter WikiText
WikiText is such a tool. It actually is very flexible, as it allows you to use a multitude of wiki dialects to write your documentation. It also supports a number of output formats (HTML, Eclipse Help, DITA, DocBook and FOP). What's more, it features a really nice text editor that can display Wiki markup almost in a WYSIWYG fashion. WikiText is developed and maintained by David Green.
So, without further ado, here is a quick introduction on how to install WikiText, writing your first document and transforming it to HTML.
Installing
Make sure you have a recent version of Eclipse installed. Then:
- Point your update manager (Help -> Install new software) to the Mylyn Update Site (http://download.eclipse.org/tools/mylyn/update/weekly/e3.4)
- Select the most recent version of Mylyn WikiText (as of this writing, this is WikiText 1.1.0.I20090423-1700-e3x) and install
After the obligatory Eclipse restart, you can start using the WikiText editor.
Writing your first document
- Create a new project (File -> Project... -> General -> Project
- Create a new file. We will be using the Textile wiki syntax, so let's name it HelloWorld.textile
- Enter some text:
h1(#id). An HTML first-level heading Textile syntax is really simple. You can _emphasize_ text or *emphasize it even more*. Scaled images: !{width: 50%}images/eiffelturm.jpg! Enumerations also are very easy: * An item in a bulleted (unordered) list * Another item in a bulleted list ** Second Level ** Second Level Items *** Third level # An item in an enumerated (ordered) list # Another item in an enumerated list ## Another level in an enumerated list Let's have more headings: h2. An HTML second-level heading Here is a table: |_. Header |_. Header |_. Header | | Cell 1 | Cell 2 | Cell 3 | | Cell 1 | Cell 2 | Cell 3 | h2. An HTML third-level heading Here is some code: bc.. package org.eclipse.workflow; public class Workflow { } p. Here is a plain old paragraph. It needs to start with "p." to mark the end of the code block above. h4. An HTML fourth-level heading Of course, we can also have hyperlinks: "Peter's homepage":http://www.peterfriese.de h5. An HTML fifth-level heading h6. An HTML sixth-level heading - Create a new subfolder images and place an image in his folder. I used this one.
You can always switch over to the preview pane, but you will notice that the source editor already does a decent job at rendering the text in a kind of WYSIWYG manner:

Transforming your document to HTML
In order to convert your document to a nicely rendered HTML document, just right-click on HelloWorld.textile in the package explorer and select WikiText -> Generate HTML. This will create anew file HelloWorld.html in the same directory. Double-click it to open it with a browser:

Automating, PDF, splitting documents,...
I hope I could whet your appetite. In the next installment, I am going to show you how to automate the process of transforming WikiText documents into output documents, how to create PDF (by way of exploiting DocBook) and how to split your documents into smaller chunks so you can work on them as a team. Stay tuned!
How Twitter solved my P2 problems during my lunch break
Today, I wanted to migrate from Eclipse 3.5M5 to Eclipse 3.6M6 (I know, it's a bit late for that already - but then, I had been busy with #eclipsecon and preparing the Stupid Modeling Talk during the past weeks).
As of course I've got quite a number of additional bundles installed (e.g., EMF, Window Builder, Mylyn, Xpand and Xtend), I wanted to re-use them. I recalled that a while back someone (probably Chris?) blogged that it basically is possible to use an existing Eclipse installation as a local update site. However, I couldn't find the blog posting describing how to do that.
Given the fact it was about lunch time, I decided to let the #wisecrowd figure out how to solve my problem. So I twittered "desperately looking for a hint how to use an existing Eclipse install as a P2 repo. Goal:transport features from my M5 install to a fresh M6".
So, during my lunch break, the wise crowd (Kai, Ekke, Boris and Paul) sent me their opinions on the matter:
At first, it seemed like there is no solution, but in the end Paul's tweet reveals the solution I was looking for:
Add eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/ as a local update site.
All of you out there who still doubt the practical use of Twitter: you really should give it another try.







