Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EMF DiffMerge/Model Patch

Introduction

The modelpatch tool can create modelpatches based on the difference of two models, and it can later apply these patches on models.

EMF DiffMerge Patch UseCases.png

EMF DiffMerge Patch WorkflowPatchRecord.png

EMF DiffMerge Patch WorkflowPatchApply.png

Model patch representation

The Patch Representation contains an ordered collection of model patch entries and metadata information, such as author and time stamp. Model patch entries represent elementary model changes. Every entry has a direction (ADD or REMOVE) and a context identifier which identifies the modifiable element. We use three type of entries: (1) element entries, (2) attribute entries and (3) reference entries. Element entries represent an object creation (ADD) or an object removal (REMOVE). An element entry also stores the type of the element (as String) in both cases. We store the type even in case of removal to ensure the reversibility of the entry (if reverse patch is applied, a new object should be created). The two other type of entries (attribute and reference) represent modification of feature values. Both of them store the identifier of the feature which is modified and have an optional index attribute which represents the position of the value if the feature value is a collection. While an attribute entry stores the data type value as a string, the reference entry stores the identifier of the referenced object.

EMF DiffMerge Patch Representation.png

Architecture

The following figure illustrates the modules of the model patch framework and their most important dependencies. The framework is divided into three parts: Patch Representation, Runtime API and Model Patch User Interface (UI). The Patch Representation ('patch') is completely standalone, without dependencies to Eclipse, EMF or EMF Diff/Merge. The Runtime API depends on EMF, EMF Diff/Merge and VIATRA runtime. The user interface extends the EMF Diff/Merge UI plug-in. There are persistence modules for storing patches in JSON and EMF model formats (the latter can be persisted to XMI).

EMF DiffMerge Patch Architecture.png

Links

  • Build job: the location where the project is being built
  • EMF Diff/Merge: the host project that also provides the technological foundations upon which the Co-Evolution technology is based

Back to the top