The Acceleo editor provides refactoring actions and quick fixes

You can use the usual shortcut ALT+SHIFT+R to rename either modules, templates, queries, variables... in a coherent manner. This action can also be accessed from the menu Refactor > Rename. The interface will allow you to preview the changes before validating them.

Code Generation Patterns

The Acceleo IDE provides an extension point to help you to define your own code generation pattern proposals.

Here is an example available in Acceleo 3.0 (use the same way to define your own proposal) :

The extension point is org.eclipse.acceleo.ide.ui.proposal

The Java class implements "org.eclipse.acceleo.ide.ui.views.proposals.patterns.IAcceleoPatternProposal"

Generation patterns have been introduced in acceleo because we noticed that something that happens really often when developing code generators is the need to implement some behavior on an interface and all or part of its subtypes.

For example, let's imagine you are implementing a java generator from UML. What you want is to have a template called javaName which will generate the name of any classifier, with some default behavior and some specific behavior on classes and interfaces.

This is where the Generation Patterns view comes into play:

• Locate the cursor in the template, at the position where you want to insert your javaName templates
• In the Generation patterns view, select "[template] for all selected types" in the top part
• Select the types for which you want to create javaName templates for

Note the bottom part of the Generation Patterns views presents a hierarchical view of the metamodel you are using. Each node represents a type of the metamodel and contains all of its subtypes. So, one type can appear several times in this view, one time for each of its super-classes or super-interfaces. When you select a node (by checking the combo-box before it), all its descendants are also selected by default, but you can uncheck those you don't need.

Once you have selected the types you need, go back to the editor and activate the completion by hitting Ctrl+Space. The first choice should be "[template] for all selected types", select it.

New templates are then inserted into you Acceleo module. They are called "name" by default but you can immediately rename them by just entering the name you want. All templates will be renamed simultaneously.

Here, Acceleo has done his job, now it's time for you to do yours: implement these newly created templates!

The Overrides View - Customize an existing code generator

Thank you for following me on my "New Acceleo features" week ;-)

The Overrides view shows every Acceleo element that is accessible in your workbench (no matter your current project's dependencies). You can select one or several elements (use the checkboxes) and override them.

Note: If the meaning of "override" is not clear, you may want to refer to the official MTL Specification.

Templates displayed in this view can be anywhere in your workspace or in your plug-ins.

So, this view can be used for:

• Selecting templates you want to override (which is its main purpose)
• Navigating to templates in your plug-ins to see their implementation without having to explicitly import their plug-in(s) in your workspace.

To override one or several existing templates, just select them in this view by checking their checkboxes. Then, edit the module in which you will override the templates, place the cursor where you want to insert the overriding templates, and hit Ctrl + Space.

Select the first choice ("Selected Overrides") and hit Return. The overriding templates are then created. Note that by default, their implementation is initialized with their original implementation.

Note: A marker indicates whether a given project is accessible from yours. If this is the case, a green mark indicates everything is fine. Otherwise, a red marker indicates that you need to import the project in yours to be able to override a template it contains. For example, in the screenshot below, org.eclipse.acceleo.module.other.sample needs be imported in your current project before you can successfully override one of its templates.

Nevertheless, you can declare the overriding, it will just not compile while you have not imported the relevant project (which is done in the MANIFEST.MF file of your Acceleo project).

Rapid Text Replacement in an M2T approach

Here is a very useful trick in Acceleo. Rapid text replacement allows you to quickly replace all occurrence of a chosen piece of text by some template invocation. Case differences are inferred generating toUpper() or toUpperFirst() depending on what's needed.

Here is an example:

In a classical bottom-up approach, you have written your code first, and you now implement the Acceleo template from this code. What you want to do here is to replace all occurrences of "att1" by a dynamic behavior, i.e. by a template call.

The easiest way to do this is to select one of the "att1" in the editor, and invoke the content assistant by hitting Ctrl + Space.

The completion assistant proposes to replace all occurrences of the selected text by a template call. A preview of the result is displayed in a tooltip close to the completion window.

When you accept this option, all occurrences are replaced and you can immediately enter the template invocation needed, which is simultaneously replaced in all relevant locations.

All occurrences of att1 have been replaced by [javaName()/] (because javaName() is what was entered manually), but Att1 has been replaced by [javaName().toUpperFirst()/].

The next thing you'd want to do in the above example is to replace all occurrences of int by something like [javaType()/], and implement the javaType template to write the java type of the class attributes.

Just proceed the same way and you're done. No risk to forget any occurrence of your type anymore!

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.