What's next in EMF Compare

Indigo is now out and about; another great release shipped on time. I am always amazed that the Eclipse community manages to release each year on schedule. Congratulations to all that help make it happen!

EMF Compare 1.2.0 was part of the train again this year, I recently blogged about the new and noteworthy of that release. Now that the train has arrived, we can think of what to do next... and it looks like a busy year is coming EMF Compare! Further integration with the Team framework, graphical comparison...

Here is a quick peek of what EMF Compare could look like for Eclipse Juno next year :

Logical Resources support

Up until now, we've considered that EMF models were tied to physical files, one EMF Resource being one File on the disk. That is true in some cases ... but in many others, a "model" is not really a "file". One file holding an EMF Resource (let's call it "library") can reference multiple other EMF Resources ("books" and "writers"), and it can even be split into multiple physical files itself.

If we call EMF models "logical resources" and their files on disk "physical resources", we thus distinguish two cases for EMF Compare : 1) one logical resource mapped to one physical resource (no reference, no fragments) and 2) one logical resource mapped to multiple physical resources (an EMF model that references others, and/or is fragmented). Only the first of these two cases is properly handled for now; we've only scratched the surface of the second and handled the most common cases.

Eclipse provides us with a framework to work on logical resources and resource mappings. We've decided to take advantage of these APIs for the case of collaborative work on EMF models. The idea is to make sure that the user never ends up with a corrupt logical model by preventing him from doing anything on a single part of the physical resources' set (or warning him when he does so).

For example, if an EMF model "library.genmodel" references another EMF model "library.ecore", and there are changes in both (the name of an EClass changed, and so did the corresponding GenClass in order to react to that name change), it should never be allowed to the user to commit only one of those two files : they are part of the same logical model, commiting only one of the two physical files may corrupt the logical model (which is the case in this example). The same applies to comparing either one of the physical files with the repository : as they are part of a set, the whole set should be used when comparing.

This support is already implemented and functional with CVS; the EGit plugin does not yet use the necessary APIs, yet support is on its way and should be gradually implemented on the way to Juno.

As a result, here is what you would get with the current EMF Compare when trying to commit such linked files to CVS HEAD :


In other words, you are allowed to commit the genmodel file alone... which will prevent anyone retrieving that version from opening it from their side as it references a Class that does not exist without the change to "library.ecore". On the contrary, here is the same flow of action with the logical resources support :



Here, even though we tried to commit "library.genmodel", Eclipse forces us to commit "library.ecore" along with it in order not to corrupt the logical model underneath.

Diagram comparison

EMF Compare supports comparison and merging of any kind of EMF model. It then displays the differences in a the form of two trees side by side as illustrated below :

The tree form, however, is not the most adapted representation for all models. When comparing GMF diagrams for example, it would be interesting to display the detected differences directly on the diagram itself :

Support for this graphical representation of the differences is planned for the end of the year. More information regarding this feature (and specifications of what we intend to implement) can be found on the EMF Compare wiki.

UML Compare

We have faced since the first version of EMF Compare a number of problems when comparing UML files; problems that just could not be properly handled by the generic approach we take for the comparison.

Most of these problems come from the fact that a "semantic" change in UML is often reflected by a number of "physical" changes in the model. For example, adding an association between two classes results (with the Papyrus) in two actual changes in the model :

• a new element is added (the Association)
• a new Property is added to the target class
  

With the Indigo release, we integrated the first version of an UML-specific comparison engine in order to properly detect (and display) the semantic level differences instead of the previous 'physical level' differences.

This first implementation will be greatly improved so as to handle the most common UML diagrams (class, package, use case, sequence... the full list can be found on the wiki page), for all potential changes that can be applied in them.

For example, the Indigo version of the UML comparison engine does not handle specifically message additions, which thus result in seven differences detected :

While the current implementation (which will be available for the Indigo SR1 release later this year) properly handles them and displays a single change :


Indigo is out, time to move on to these exciting new features... Well, almost :). For now, 'tis time to relax a little bit. Sun, beach and beer seem like a perfect combination to that end :).

What's new in EMF Compare

Here we are again, it is almost time for the annual Eclipse release; this year for the sixth consecutive named simultaneous release. EMF Compare has been there since Callisto, the first of those six; and EMF Compare 1.2.0 is now on its way out. So, what has been added to this new release?

Among the usual bug fixes, we have added some noteworthy features :

Difference grouping

EMF Compare can detect a number of differences between models; additions, deletions, moves... It is now possible to "group" these changes by type in order to read the comparison with a little more ease.


New Grouping strategies can also easily be contributed by client plugins; more information can be found on the dedicated wiki page.

Difference filtering

It is now possible to filter out some of the differences from the EMF Compare UI. For example, here is the same comparison as above without the "added" elements :

As for grouping, new filtering strategies can be contributed by clients plugins. Detailled information on this feature can be found on the wiki.

Textual comparison of attribute values

If a change in an attribute value has been detected by EMF Compare, it will display, by default, a message such as "attribute : in class has changed from to ". This message is hardly readable for long "string" values of attributes. EMF Compare now allows you to get a dialog displaying the textual comparison of those values :

As usual, detailled information can be located on the corresponding wiki page.

UML-specific comparison engine

EMF Compare provides a "generic" comparison engine that works on every EMF models you can find. The disadvantage of a generic engine, though, is that it cannot know of specific needs. UML models, for example, have a number of features that EMF Compare cannot properly handle in a generic manner.

We now provide along with EMF Compare 1.2.0 an UML-specific comparison engine to take care of that metamodel. For example, here is what the generic engine detects when applying a stereotype to a Class :

And here is what can will be detected and displayed by the UML specific engine :

This UML comparison engine is still in its early stages and will be improved in the months to come, but it is still provided for early adopters. Further technical information about this extension are described on the Eclipse wiki.

Most of these features have been implemented as part of the Modeling Platform working group.

Acceleo query cache

Some of our users have been bit by the fact that Acceleo caches the result of Query invocations, returning the very same result each time a given query is called. These users often came with the same two questions : "why?" and "Can this cache be disabled in my case?".

The answer to the first has always been and will remain the same : Acceleo is an implementation of the OMG's MOFM2T 1.0 specification, and this specification tells us that

• A query is required to produce the same result each time it is invoked with the same arguments.

That is the reason we decided to cache the result : in order to return that same result each time the query is called, without re-evaluating it.

The answer to the second, however, changes with the 3.1.0 release of Acceleo : even though we strive to be as close as possible to the specification, there are times where this caching of the query return values is not desirable : it can be really costly memory-wise, it could be a call to a Java method that has random results, it could be a query which return value changes according to variable states that are not passed as parameters... That was possible through programmatic calls in 3.0.2, but we've decided to make that preference available through the UI in 3.1.0 :


The next step is to have the specification evolve in order to be able to disable the query cache "per-query" instead of globally but... that's another story :).

Acceleo syntax coloring

I announced in my latest message that the syntax highlighting colors of Acceleo would soon be configurable. Well, the preference page has now made its apparition and will definitely be available in the 3.1.0M7 build of Acceleo.


If anyone would like to contribute, we're still missing import/export capabilities to make these color themes easier to share between Eclipses and colleagues; we'd gladly accept such contributions :).

Acceleo over the rainbow

We've often had complaints about the default choice of colors we made for the Acceleo template editor :


For example, people who like high contrast themes, or who'd rather develop with a white/green font on a black/gray background complained that this colors were unusable when using such backgrounds. And since we inherit the background color from the default "text editor background" color, this could give awful results :


There were also those that simply didn't like to have "red" text in their code, since this color usually reflect an error of some kind :). As hinted from Stéphane's recent post, we've decided to make these colors customizable in Acceleo 3.1. And even though his "rainbow" theme was a little extreme (just in time for april's fool), it did show a number of the areas that now get individually customizable.

We hope to include import/export facilities for these color schemes, and the rainbow scheme will most likely be included along with the default :).

I know my editor will more or less look like this (but I kind of find blue-ish themes easy on the eye) :


How will be yours? Look forward for the 3.1M7 build for these options :).

Acceleo vs Acceleo vs Xpand

We've recently had a good number of people asking for comparisons between Acceleo 2 and its new major version Acceleo 3. Some people also wondered how Acceleo ranked compared to the other trendy code generation tool, Xpand. The three have the same goal : generating text from models, let's take a closer look at their respective performances.

With the migration capabilities we have between Acceleo 2 and Acceleo 3, comparing those two has proven rather easy; comparing them with Xpand has been a little more trouble for me as I am not familiar to this tool. I still attained a result I believe to be interesting.

I didn't make in-depth comparisons between the tooling of each of these three tools, focusing on the generation performance only. GUI comparison may come later, when I have the courage :).

What I did compare was the generation performance for a given set of generation templates that I ported to all three of the technologies. The result is that all three tools (Acceleo 2, Acceleo 3 and Xpand 1.0.1) generate the very same java code, whitespaces excepted.

Each of the times outlined below is the average of three runs on the same machine :
- Intel Core 2 Duo 64 bits
- Dual core, 2GHz by core
- 4 Go RAM
- Windows seven 64bits

The version of Java installed on this machine was Java SE 1.5.0_22 64bits.

The Eclipse platform version was Eclipse Helios 3.6.1 (64 bits still). Each tool was installed within its own Eclipse with only its dependencies and the dependencies of the tests.

I've run two distinct use cases for this benchmarking :
- "Small" corresponding to the generation with a small model as input. I used UML.genmodel for this, which in turn links to UML.ecore, Ecore.ecore and Ecore.genmodel. When counting the content of the two main models used by this transformation, UML.genmodel and UML.ecore (just a basic count of eAllContents), I get a total of 14 420 elements.
- "Medium" corresponding to the generation of medium models as input. For this, I generated a metamodel with a fixed number of classes, enumerations and datatypes, then the corresponding genmodel. Like above, a basic count of the model content yields a total of 50 944 elements.

As far as generated files go, the "small" use case generates 217 java classes for a total of 200 921 lines of code. The "medium" use case generates 1 206 java files for a total of 838 273 lines of code.

All measures have been taken "at worst", launching the generation in a new Eclipse runtime (thus, nothing in cache, no plugin loaded yet). The times given here are in seconds, and they correspond to the average of three runs. One measure comprises the time to load the model, the time to evaluate the generation and the time to serialize the result.

Without further ado, here are the figures :

	Acceleo 2	Acceleo 3	Xpand
Small	50 s	10 s	25 s
Medium	215 s	25 s	212 s

Being an Acceleo developper myself, I can only be pleased by these results ... Even though the test might be seend as biased as a result :p. All of the files needed to replay these can be downloaded from here. On that matter, as I am not familiar with Xpand, please don't hesitate to optimize the templates if at all possible (though the Acceleo 3 templates themselves don't use the latest evolutions of Acceleo 3.1).

Open World Forum Demo cup award 2010

The Open World Forum took place in Paris on September 30 and October 1. This was a great opportunity to discover open source tools and technologies, as well as getting to know great people of this field. The 2010 edition has attracted over 1500 participants from 40 countries!

Obeo was present and demonstrated the use of Acceleo 3 to generate android applications, this demo earned us the Demo Cup 2010 award! This award is given to recognize the most innovative and game-changer open source solution in its marketplace.

Acceleo, selected from 13 top nominees, received one of five prestigious trophies at the closing ceremony of the Open World Forum, awarded by a jury consisting of leading international experts in the open source world.

After the Eclipse Community Award in 2009, this prize recognizes the constant efforts of the Acceleo team & community to provide a powerful tool of the highest quality.