Acceleo is a code generator who implements the Model to Text tranformation language standard from the OMG (MTL). Acceleo generate codes from an EMF model with templates. It can generate any kind of source code, and you can find in the examples and tutorial some generator for Java, XML, Python, etc. Acceleo can be used in a stand alone environment to compile MTL files and to execute the code generation. You can also use the compiler and the engine with a good old java project. You can find more about the features available in Acceleo here.
Context of the development of the prototype
During the summer 2010, one of the member of the Acceleo dev' team started, at Obeo, to work on that prototype in order to evaluate the new Eclipse platform, e4. In order to do that we started to create a prototype of Acceleo running on e4. So first let's clarify a thing or two. E4 is the project that has been created to develop and test the technologies that will be included Eclipse 4. At the time, the first release of Eclipse 4 has been made with components of e4. This version of Eclipse 4 contained the JDT, and all the classic tools of the Eclipse platform. Those tools are the same as in Eclipse 3.6 Helios and the are running on the top of a compatibility layer. This compatibility layer allows people to run Eclipse 3.x plugins on Eclipse 4.
Acceleo on the compatibility layer
We tested Acceleo with the compatibility layer and it's fine, there were a bug or two here and there but most of the features were fully functional. The goal of that prototype is to have Acceleo running on e4 without the compatibility layer.
Acceleo on e4
At the time, e4 was a nice set of APIs and frameworks but since most of the existing code of the Eclipse platform had not been ported yet to e4, there were several problems with the transition from Eclipse 3 to e4. The first and biggest problem was the fact that the bundle org.eclipse.ui had not been ported to e4. Which means, if you wanted to create some UI element you pretty much had to start from SWT/JFace widgets.
And when we worked on this prototype, it was before the release of Eclipse 4.0 and there was pretty much no documentation except a tutorial or two from Lars Vogel and some examples on the CVS like the Simple IDE from Tom Schindl which was a great source of inspiration for this prototype.
Architecture of the prototype
Let's see the architecture of the prototype first. Since at the time, the platform was just a nice set of APIs, we pretty much had to build a complete RCP application from scratch. The base of that application had to offer the basic functions of the Eclipse IDE. For that we started to create the UI model of this basic application.
In e4, pretty much all the UI extension points have disappear from the plugin.xml and there are now contained in a single EMF model which describe the UI. You can see that the organization of this model allow us to manipulate all the UI concepts more easily. Since it's an EMF model you can also use all the tooling created by the modeling community. That basic EMF model allow us to describe the base of this RCP application. With this, we started to create the ui bundles of the Acceleo prototype that would contribute to this basic application. These contribution are also done thanks to an EMF model as you can see it in the next screenshot.
UI development on e4
Quickly after the beginning of the realization of that prototype, we decided to test some other UI technologies available with e4. First we tried the CSS. You can see in the next screenshots the prototype with and without CSS.
So let's be clear with the CSS on e4, it works, it' easy to use, it is the same old CSS that everybody knows. Yet we didn't succeed in creating something beautiful with CSS because we are not designers and we will stick with the default look and feel anyway. But for a RCP application, CSS can be a very simple way to customize efficiently the design of your application.
Since we were testing the UI, we also tried XWT. XWT is not, a part of the e4 platform but since it's coming with it, we tried it at the same time. Creating the UI with a WYSIWYG editor and after that serialize it is a great idea and a WYSISWYG tool for Eclipse is a good idea, because let's face it UI code is always ugly and you can't picture the result easily.
When we tested it, we were not fond of the tooling of XWT and we would have preferred something based on an EMF model. On the top of that the binding system was quite complicated. We tested it during the M7/RC1 of e4 and we didn't expected a perfect product, yet we were disappointed. It was easier to work only with the XML and then use the XWT runtime.
First look at the prototype
So here you can see the prototype running, with the editor and some very basic features. I would like to point out that working without the org.eclipse.ui bundle includes having to create an editor back from a simple TextViewer. All the nice classes like AbstractTextEditor are gone. The problem is that with the TextViewer comes lots of JFace object manipulated by their interface like the annotation model for example. Those interface are nice but since their only implementation is in org.eclipse.ui, you cannot have the quality of an Eclipse 3 editor with markers, auto-completion or quick fixes unless you are the guy who wrote it in the first place.
Working with the new platform
The communication with the Eclipse platform is know done in a very different way thanks to dependency injection. This change pushed us to modify some part of our architecture to go to something closer to a service based architecture. You can see here some example of dependency injection with e4. After some difficulties at the beginning, I have to say that the dependency injection is a very nice way to communicate with the platform and with other bundles. It was easy to determine where each injected value was coming from in this small environment, but I have the feeling that debugging dependency injection in a crowded environment may be a bit more painful. Anyway, some major Java enterprise frameworks switched to dependency injections years ago, it didn't kill them, personally I loved it in e4.
I also used the new event system of equinox, the event admin, in order to send and receive events across the platform. It is one of my favorite features in e4. This is a way to replace the traditional observer pattern. Instead of communicating one with the other, the provider of the event and the listener of the event are communicating thanks to the platform and as such have no idea were the event is coming from and who is listening to the event. If it is well used, it could reduce the dependency between components inside the platform. My only fear was to overused it.
Features of the prototype
As you can see it the prototype possess the basic function of Acceleo with the editor, the compiler and the engine to generate code. During this small demonstration, we will create a small Acceleo project, in this project we will have a very small template (it is not a demonstration of what Acceleo is capable of after all) and then with this small project and with a small EMF model we will generate a small html page describing each EClass of the model.
In order to sum up this experiment, I would like to say that I am looking forward working on e4. Dependency injection appears to be a very nice way to interact with the platform. I am looking forward the first version of the JDT in order to try to improve this prototype and maybe create the first elements of what could be one day Acceleo 4.
This report was presented at the "Modeling symposium" during "Eclipse Summit Europe 2010" in Ludwigsburg, Germany by Stephane Begaudeau.