Acceleo 3.0 Non-Code Aspects

I was preparing the Eclipse Helios Release review material for Acceleo 3.0 and I had to compute the following information... I thought it could be interesting to share these Non-Code aspects with the Acceleo community...

JUnit Tests metrics :

• 706 unit tests are launched on every build
• 1219 unit tests are launched every day

JUnit Tests Code coverage :

• 71 % for the code generation engine
• 84 % for the MTL compiler
• 29 % for the Eclipse UI - We plan to reach 50% in the next few weeks

Code quality information :

• Checkstyle is activated on each distinct plug-in
• Eclemma is used on a regular basis to improve test coverage
• Yourkit is used on a regular basis to improve performances
• Javadoc represents more than 46% of the Java source code

A code analysis page is available on Ohloh.

Don't hesitate to become a friend ;-)

Acceleo - Documentations are available

The documentation that comes with Acceleo 3.0 is ready. Everything is available in the Help menu : Help > Help Contents > Acceleo Model To Text Transformation Language.

Each document of the documentation set deals with a different aspect of mastering Acceleo :

• Plug-in Overview : This will give you at a glance a quick overview of what Acceleo offers.
• Quick Start : This document is meant to help you get started with Acceleo as fast as possible. No details, no explanations, just the facts!
• Android Tutorial : This is meant to give beginners a tutorial to get them started with defining their own code generators... and advanced users a way to discover some of Acceleo killer features.
• User Guide : This document describes each and every feature of Acceleo. From the installation to the execution with a trip through the editing features, it will give you an in-depth description of everything there is to know about Acceleo.
• New Acceleo Project : A short description of what a new Acceleo project has to offer (and how it should be laid out) in terms of files and features.
• New Acceleo UI Project : Acceleo allows you to create "UI Projects" to ease the bundling and deployment of Acceleo generation modules. This short document will lead you through this process.
• OCL operations reference : This is more of an OCL documentation, but this will give you an exhaustive list of the available OCL standard library operations, a short description and examples for each of them.
• Acceleo operations reference : Same as the above, yet this time for the Acceleo standard (and non standard) libraries. Once again, a short description and examples for each of these operations will be listed.
• Text Production Rules : This document is more of a normative document than it is an end-user documentation; it will help you understand the rules that Acceleo uses under the hood in order to determine when indentation should be swallowed, when lines should be indented, when lines should be trimmed...

Have fun and do not hesitate to give feedback through the mailling-lists, the bugzilla or the Eclipse M2T newsgroup! (you have to put the tag [Acceleo] in the message subject)

Acceleo Pre-Conditions to improve adaptability

Imagine you want to implement different behavior for a code generation template depending on certain conditions.

One way to do that would be to use if blocks to distinguish between those cases.
Another, more elegant, way is to use pre-conditions. Let's say that you want to generate different code for associations whether or not they are declared ordered.


The above example shows the ? (condition) syntax that tells Acceleo that the template must only be run if the pre-condition is satisfied.

The Acceleo Result View

In Acceleo 3.0, the Result View shows how the text, the templates, and the models are synchronized. After a code generation, select any element in the Result View and the associated generated code will be highlighted. Likewise, select any piece of code in a generated file, and you will see the associated element in the Result View.

You can also right-click on an element in the Result View and run: Open declaration. This will open the Acceleo expression associated with the element.

Dynamic Ecore with Acceleo - Editing and packaging

In the Android example I presented at Eclipse Con 2010, we start by creating an ecore file with a set of domain model elements, including the "Activity" and the "Widget" concepts. When editing the code generation MTL module files, we need access to the Android ecore concepts. We need to improve both the ecore file and the code generator. It's easier to do if we are able to edit the code generator and the domain metamodel in the same eclipse instance.

We identify the domain ecore metamodel with its NsURI. In Acceleo 3.0, it is now possible to defined, in the MTL module file header, the NsURI of a dynamic Ecore/EPackage (even though it is defined in the same eclipse workspace). For instance, in the following picture, we are editing the "edit.mtl" file based on the "android.ecore" metamodel which is located in the same workspace.


The packaging of an Acceleo project is not more complicated than the packaging an Eclipse plug-in. In this case of a dynamic ecore file, you have to know that you need to export all the required plug-ins, including the project which includes the "android.ecore" file.

Acceleo 3.0 : a pragmatic implementation of an OMG specification

With Acceleo 3.0 included in Eclipse 3.6, our goal is to provide the de facto or reference implementation of the MTL code generation standard. Yet some parts of the specification are still quite vague and ambiguous and collaboration with OMG isn't smooth ... We follow as much as possible the standard but sometimes we need to introduce some deflections with the specification because we would like to keep the exemplary pragmatism of the Acceleo.org 2.x version.

For instance, we sometimes need to wrap Java services. It is useful to invoke some java code from inside an Acceleo template. The acceleo non-standard library provides a service "invoke" which allows just that. The invoked java service is wrapped in an Acceleo query. Such a service isn't defined in the specification but it is necessary in an Eclipse pragmatic implementation. For this reason, we decided to define 2 compilation modes in the Acceleo Compiler properties page. The default value is "false" for the "Strict MTL compliance" property. "unchecked" means that we allow to use the pragmatic non-standard library. When you check this value, some syntax errors could appear on your MTL files (each time you use the non-standard library) but the code generation execution still works...


Etienne Juliot will discuss about that (both the specification and the implementation) at the OMG Meeting Special Event on Tuesday 22nd June 2010 in Minneapolis...

Acceleo 2.7 is released... Destination 3.0!

Acceleo 3.0 is coming soon, with the Eclipse Helios train... Acceleo 3.0 already sports awesome stability and a level of functionality close to if not equal to its 2.x stream. We have planned several corrective versions in the next few years for the 2.x branch, the 2.7 version is out now! An official announcement will be done next week... Several improvements and bug fixes have been done for this release. You may want to have a look on the new and noteworthy page for the 2.7.0 release. We also plan to release a 2.7.1 version this year and a 2.8 version next year.

Do not hesitate to give feedback through the mailling-lists, the bug-tracker or the web forum... Note that Acceleo 3.0 users should use the Eclipse M2T newsgroup! (you have to put the tag [Acceleo] in the message subject)

Last news for Acceleo 3.0 users... We have just changed the MTL file editor icon because we would like to be as close as possible of the Eclipse user interface guidelines.

Here's an example of what we had before (the green icon) and what it looks like today...