Jump to: navigation, search

EMF Compare/Logical Resources

Logical resource support will allow EMF Compare to better handle fragmented models. Among others, this support will allow EMF Compare to prevent comparison/synchronize/commit actions without taking into account the whole set of resources the target depends on. For example, you wouldn't be able to compare a fragment without considering its parent if there are links between the two.

What are logical resources?

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.

Before commit action.png

Before commit dialog.png

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 implemented :

After commit action.png

After commit validate.png

After commit dialog.png

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.

Benefits of the logical resources support

versionned models

The primary aim of the logical resources integration are the different Version Control System's (VCS) actions (commit, update ...). The target VCS are CVS and Git (through the CVS plugin and the eGit plugin respectively). The listing below wil enumerate the distinct operations that are concerned for both of these VCS.


  • Synchronize
  • Commit
  • Update
  • Create patch
  • Apply patch
  • Compare with (all)
  • Replace with (all)


Git patches, fetch and pull are commit-based. Thus, ensuring that the commit action does not corrupt models should be enough. However we still need to check on pull that the whole logical resource is being retrieved from the remote repository. Indeed, The person that committed that resource may not have used the logical resource integration, and in such a case our goal is to warn the user that pulling that revision may end up corrupting his model.

  • Synchronize
  • Commit
  • Fetch
  • Pull
  • Compare with (all)
  • Replace with (all)

Workspace models

The benefits of the support for logical resources does not end with ensuring that versionned models are sound though. Indeed, some of the operations a user can make in the Eclipse workspace may end up corrupting his models if he does not pay enough attention.

For example, changing one of the fragments of a logical model without loading the parent, moving that fragment in a new repository ... or deleting it altogether. The different operations that could cause the corruption of a logical models include :

  • Deleting a physical file that is part of a logical model
  • Moving a physical file that is part of a logical model

But also changing a physical file that is part of a logical model in any case that alters one of its EMF element's URI :

  • changing the ID EAttribute
  • changing the XMI ID
  • moving the element to a new container
  • deleting the element