How to create an Acceleo 2.x generator for composed metamodels

Imagine you have a metamodel that reference other metamodels and you want to create a generator for this metamodel. Let's take an example :

The first metamodel contains an EClass named Object that have a reference package of type EPackage. That create a reference to the ECore metamodel.

First we have to create a template for the first metamodel :

<%
metamodel http://www.obeo.fr/first

import manymetamodels.ecore
%>

<%script type="first.Object" name="default" file="test.txt"%>
Object <%name%> :

<%package.default%>

Then we need to create the template manymetamodels.ecore.mt :

<%
metamodel http://www.eclipse.org/emf/2002/Ecore
%>

<%script type="ecore.EPackage" name="default"%>
EPackage <%name%>.


And that's all. So you just need to create at least one template per metamodel and then inport them according to the way you navigate your metamodels.

Agility 1.4 is out

Agility is a product based on Eclipse that help migrating code. You can find more details here. This new release comes with several improvements :

- Custom link resolution
- OStore reflective editor
- Export to product parser

There are also bug fixes of course :)

Acceleo 2.7 is out

There are several improvements and bug fix :

- Profiling now profile compilation of templates. EObjects profiling can
be also disabled. It's very useful when generating from big models.
- EA models import has been improved
- Some improvements have been done on resource caching
- A template extender have been added. It allows to explicitly extends
template from a module. It relay on extension point.
- It's now possible to add custom services as system services. For those
services the import statement is not required.
- The import order error has been changed into a warning.

For a more complete list you can visite the official Acceleo web site.
To download this new version you can use this update site http://www.acceleo.org/update.

New succes for Agility

Obeo Agility is a proprietary product edited by Obeo. It's used for code migration. It parses legacy code into a model used for generating code for the targeted technology. We already parse and migrate millions of code lines from many languages (Cobol, Ada, PL1, ...). We finished a project for parsing 5 millions of code lines written in Natural. The goal for this project was not migrating the code, but automating code review. Reports are generated using... Acceleo.

Profiling your code generation

I am now developing on the Eclipse Acceleo project. To get started I bring a feature form the old Acceleo project. I write a profiler for the new Acceleo. It's very similar to the old profiler.

As you can see the screen shot show many statistics about the module execution. By double clicking on an element you can open its definition.

Thread safe services

Last month I explained how to tune Acceleo standalone engine threading. But services were still running in mutual exclusion because historically services didn't need to be thread safe. The result was a performance loss.
Services of a given service class couldn't run in parallel by default. It means threads will have to wait for other threads to run services. I noticed that a lot of service classes are thread safe, they don't use field or static references.

But as I can't decide if a service class is thread safe or not for you, I added an interface that bypass the mutual exclusion zone for a given service class. It allows multi threads to run services of a service class. This interface is IThreadSafeService. It declares nothing, so you just have to add the implements clause as following:

public MyServices implements IThreadSafeService {
...
}

But be aware, if you use this interface and your service class is not thread safe it can lead to random boggus behavior. And it can be difficult to find out what is the root cause of your troubles.

Acceleo standalone and multi-threading

One of the main features of the standalone Acceleo engine is to provide multi-thread support. This allows us to divide the code generation time according to the count of available processors, effectively cutting the generation in half on some machines. To share the work between threads, the input model is divided into groups of objects; each group is then queued till a thread can process it.

There are two parameters to tweak the multi-threaded generation. The first one is the number of threads to run simultaneously, the default value being the number of available processors plus one. This allows us to use all available processors, the one supplementary thread used to cover synchronization waiting time. While some threads are waiting for another one, one processor is free to run the thread which was waiting for an idle processor.

The second parameter is the number of objects per group, the default being 20 objects per group. This parameter is very important since its allows you to find the optimum between load sharing and thread management overhead. Your objects groups will not be processed using the same amount of time. So Imaging you divided your model into two groups by setting number of objects in the model divided by 2. The group which runs faster will have to wait for the slower group at the end of the generation. In this case you are losing time. On the oposite you can put a single object per group. This way you minimize the loss of time at the genretation end. But threads will spend more time peeking groups in the queue since there are much more groups.

To set thoses parameters have a look at :
- Extension.setThreadsNumber(int)
- Extension.setEObjectsPerThread(int)