Thursday, June 16, 2011

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.

Tuesday, June 7, 2011

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 :).