Last Friday we (eclipse.org) officially released the M5 of the Helios release train. Xtext, being part of the train, got a couple of new & noteworthy features we (Xtext team) are very happy (and sort of proud) with.

I'm personally most excited about the new builder infrastructure, which allows to revalidate, index and build any kind of EMF resource. Some of the new features we added in M5 demonstrate the huge potential of that builder infrastructure. My favorite is the open element dialog, which I use frequently. Besides that we also added a couple of other features like, auto editing, bracket matching and styled label providers. Our new & noteworthy document shows the most important feature additions using screenshots and small screencasts (we hope you like it).

During M6 we will add some features as well as doing the regular bug fixes. Also we will do a major rename refactoring (actually it is already done), so you might face some migration efforts when you upgrade. For M7 we are going to focus on performance improvements and further bug fixing. Documentation, tutorials and migration guide will be worked on during the RC phase. In parallel we're working on a new general purpose language developed in Xtext. It is meant to be some kind of library. Everyone should be able to reuse, adapt and extend that language within her own Xtext languages. That language won't be released with Helios, but as it is open-source you might be able to check it out by that time.

Btw.:
Have you already voted for the Eclipse Community Awards?
No? Go here.

In conjunction with the Eclipse M4 release of Xtext its website has been updated, too. We wanted the new features to reflect how lively the Xtext project is by just looking at the website. At the same time, they should not scare away new visitors but be informative and subtle.

In the end we came up with: Some statistics of the project activity (1), a news aggregator (2), and a condensed (53 secs) introductory screencast (3).

Our project website attracted some attention since it has been launched this June. The AMP project reuses its layout and Denis from the Eclipse webmaster team embraces the results, too. From there, the bugzilla 235828 discusses whether the Xtext website should serve as the standard template for new Eclipse projects.

Currently, you can see such an “empty Xtext website” at eclipse.org/default - how cool is that!

The Bells and Whistles

Even if Denis, Matt & Karl will provide a standard template based on the Xtext website you might want to adapt some of our additional features, too. To support you in doing so, I will summarize the underlying technology of the recently introduced features.

To produce the commit stats (1) the page leverages the commit statistics of Xtext and renders the polished data with the Google Chart API on order to match our visual expectations.

The news section has been built with Yahoo Pipes to scan, filter and aggregate different web resources asynchronously. You can even subscribe to the news feed directly to always stay up to date.

For both the commit stats as well as the news section Denis allowed me to install a cronjob that fetches and stores the results independently from the http requests.

The screencast has been recorded and edited with ScreenFlow. Also, thanks to Sven for the audio equipment!

Let me know if you want me to provide more details.

The M4 of the current development stream of Xtext (Helios) finally contains the long awaited builder infrastructure. This topic turned out to be a very complex beast, and although we already took two attempts the last one took us about six weeks of very intensive work. But we love the result :-)

What is this builder infrastructure for?
I'd already blogged about the idea of name space based linking.
The builder infrastructure collects lightweight descriptions of all Xtext resources in the workspace. The linking can then use this information. In addition we use this information to compute the transitive hull of affected resources.

Also the builder takes care of validation and will support an extension point where users can hook in code generators and the like. Other features where we'll make use of the new information includes: more sophisticated searches, call graphs, and of course find reference actions. A generic rename refactoring is also something we want to start working on as soon as possible.

The documentation will be updated during the RC phase.

The New & Noteworthy page contains a short screen casts showing the builder in action:



Dirty State aware editing

Note, that state in the builder is shadowed by any dirty editor state:



What about the EMF Index?
Wasn't the EMF Index intended to do this?
It took us some time to find out what Xtext really needs, and in the end we learned that there are a couple of important specialties, like the lazy linking or the linking by name. We didn't want to add those concepts to the EMF index. Therefore we started out to solve the actual problem in Xtext first and later see if the requirements fit and can be handled by the EMF Index project. As a result we came up with a very small interface which can be implemented to use the EMF Index as soon as it supports the needed use cases and is mature enough. Most of the stuff we did is Xtext related, the code which might be replaced by the EMF Index is just a couple of lines.