Difference between revisions of "EMF Compare/Epatch"

Latest revision as of 11:59, 5 March 2014

THIS PAGE IS ARCHIVED. IT IS PROBABLY OUTDATED AND WILL NOT BE UPDATED

About & Motivation

The Epatch format aims to be for EMF models what the classical patch (originated in the UNIX world, nowadays used with CVS, Subversion, GIT, etc.) is for text files. Creating a classical patch for a model means to create the patch based on the model's XMI file. This has several disadvantages:

• it is not human-readable, since XMI is already difficult to read for the untrained eye.
• it tends to contain a lot of unnecessary information: For example, when the formatting of the XMI file is changed (indentation!) or elements and attributes are interchanged, this typically doesn't mean a change for the model, but a huge change for the classical patch.
• it can not be analyzed by machines: It can not be determined which model elements have been modified, added or removed without having the XMI representation of the to-be-patched model available.

The Epatch format has been contributed (and is further developed) by Moritz Eysholdt (moritz.at.eysholdt.dot.de).

Features

The following operations can be executed...

• The EpatchRecorder records Epatches (buggy), like EMF's ChangeRecorder records ChangeDescriptions.
• The DiffEpatchService creates Epatches from EMF Compare's DiffModels and MatchModels
• CopyingEpatchApplier applies an Epatch by creating a new model which is the patched version of the original model. The original model is untouched.

The Epatch format...

• is bidirectional, i.e. a patch that allows to upgrade model A to model B can as well downgrade model B to model A.
• is meta model (Ecore model) agnostic, i.e. the to-be-patched model's meta models can be Ecore itself or any other Ecore model.
• is self-contained, i.e. Epatches can be read, displayed, processed etc. without having the to-be-patched model available.
• is an EMF model and therefore has an Ecore-based meta model.
• is declarative (as opposed to a sequence of change-operations)
• is able to describe copies and moves of model elements.
• supports multiple resources
• has an optional textual representation, which is based on TMF Xtext

Setup without support for the textual representation

1. Set up your development environment as described for EMF Compare via the team project set.
2. Go to the CVS Perspective in Eclipse, it should now show the location "dev.eclipse.org:/cvsroot/modeling". Navigate to "org.eclipse.emf/org.eclipse.emf.compare and additionally" fetch the projects
   1. plugins/org.eclipse.emf.compare.epatch
   2. tests/org.eclipse.emf.compare.epatch.tests

Setup with support for the textual representation

1. Install Xtext in at least version 0.7M6a. The most convenient way to to so is to download the Eclipse Distribution "Eclipse 3.5M6 Galileo + TMF Xtext 0.7M6a" from itemis AG
2. Follow the Setup without support for the textual representation.
3. Additionally fetch the following projects
   1. plugins/org.eclipse.emf.compare.epatch.dsl
   2. plugins/org.eclipse.emf.compare.epatch.dsl.ui
   3. tests/org.eclipse.emf.compare.epatch.dsl.tests

Getting Started

There is not much to see yet, except for green JUnit tests. Please use them as entry points for diving into the code.

Status

TODO:

• make the code pass the checkstyle tests
• extend the patch format to be more fault tolerant when being applied to slightly modified models
• UI integration to create patches: implement EMF Compare's org.eclipse.emf.compare.ui.export-extension point, so that Epatches can be saved from EMF Compare's difference viewer
• UI Integration to apply patches

Support

Feel free to ask question in the eclipse.technology.emft newsgroup (web)