EMF Compare/Contributor Guide
- Developing on EMF Compare requires the use of Eclipse 3.5 (Galileo) at least, though it is possible to use the latest releases as well.
- It can be obtained through the Eclipse download page. The easiest way to set up your environment is to download the Eclipse Modeling Tools bundle since it will already contain most of our dependencies, except for Guava.
- All of the following can be obtained through the simultaneous release's update site. From the Eclipse you've installed, use the Help > Install New Software... menu. In the dialog that pops up, locate the update site of your release (it should be labelled Eclipse <name of release> Repository). The list that loads below will contain the necessary projects that you just have to install.
- We'll go through how to obtain them separately.
- EMF Compare depends on version 10 of google's Guava library. It can be installed from the Orbit update site. Do note that EMF Compare is not compatible with version 11 or higher of Guava.
- EMF Compare heavily relies on EMF and requires version 2.5 at least. We recommend using the SDK so as to have access to the sources as well.
- Get it from the EMF downloads page.
Checking out the code
The code of EMF Compare is located on a git repository. You can check it out with the command :
The repository contains three folders at its root :
- org.eclipse.emf.compare-parent is a non-code plugin which serves as the location of our parent pom. It otherwise contains our target platforms, checkstyle and formatter configuration...
- packaging contains all of our features as well as the project's update site.
- plugins contains the actual plugins of EMF Compare. More on these below.
The plugins can be further divided in a number of "sets". Depending on what you are planning to do, you might not need to import all of these sets. All of our plugins' name are prefixed with org.eclipse.emf.compare. For the sake of brevity, this prefix will be abbreviated to o.e.e.c in the following.
EMF Compare Core
The core is the bare minimum you need to call for EMF Compare to compare your models. It is meant to be useable in a standalone application and has no adherence whatsoever to the Eclipse platform.
- org.eclipse.emf.compare is the only plugin of this "set".
Likewise, all of its unit tests are standalone, though they have a wider range of dependencies (most notably, UML2 and emfstore).
EMF Compare UI
The user interface of EMF Compare is fully integrated within the Eclipse IDE. It is comprised of the following plugins :
The unit tests of the EMF Compare user interface require SWTBot :
EMF Compare offers a customized comparison engine for UML models and their specificities. This extension is made of the following plugins :
GMF Diagrams Comparison
EMF Compare offers a specific customization for GMF models and the graphical display of differences. This extension is implemented within these plugins.
Specific extensions for some modelers are also available :
Developing EMF Compare patches or code
Every new feature or major change should be documented in a short specification, the template is available here
The EMF Compare team uses Checkstyle with its own set of rules in order to have an homogeneous code style throughout the plugins and features.
The Eclipse plugin for Checkstyle can be downloaded on sourceforge. EMF Compare makes use of EMF Compare 5.*. Once installed, it will be automatically applied to all existing EMF Compare plugins as they are already configured to use it.
You need to have the org.eclipse.emf.compare-parent plugin in your workspace.
New projects should use the same set of rules :
- Right-click on the project on which to configure Checkstyle and select "Properties",
- In the "Checkstyle" category, go to the "Local Checkstyle configuration" tab,
- Hit "New" and select "project-relative configuration" from the "type" drop down menu. Set the name of this configuration as you see fit ("EMF Compare" for example) and click the "Open..." button for the localisation.
- Browse to "org.eclipse.emf.compare-parent/codeStyle" and select EMFCompareCheckstyle5Configuration.xml. Hit "Ok" twice to end this wizard.
- Go back to the "General" tab, then tick "Activate Checkstyle on this project"
- In the drop-down below, select the configuration you just created, then click OK to close the properties dialog.
- That's it. Your project will now go through the EMF Compare Chekstyle rules on each compilation.
Note that Checkstyle errors are not considered fatal compilation errors : you can still run code with checkstyle errors. Nearly each of EMF Compare check is set to report an error though, as we always try and comply to these rules.
At first, most of the checkstyle errors that will be reported will probably be formatting errors : you can configure your formatter to use EMF Compare configuration to avoid these.
- Click on Window => Preferences
- Browse to the "Java => Code Style => Formatter" category and click on the "Import" button
- Browse to the "<workspace>/org.eclipse.emf.compare/codeStyle" directory and select "EMFCompareformatter.xml"
- hit Ok twice to close the preferences dialog
Your formatter will now comply to EMF Compare code style. Hitting ctrl+shift+F in a java editor will format your class to follow this style.
Note that all EMF Compare plugins are already configured to make use of this formatter
EMF Compare is built against Java 1.5 : usage of the JDK 1.6 API will result in build errors and should be avoided.
We try our best to ensure downward compatibility towards Eclipse Europa, as such we use the following as our target platform :
The target platform is added both UML2 and Subversive for maintenance of the examples and the subversive integration feature
The target platform can be set through the preference page accessible via Window => Preferences => Plug-in Development => Target Platform. More information on how to set a target platform for development can be found in the Eclipse help.
The EMF Compare development team uses the target platform augmented with the M6 EMF Compare build to maintain API compatibility. Checks for API breakages and evolutions are set per project and committed alongside them. All of these settings are still soft and don't ensure full API compatibility for now, they will be changed for strict API maintenance as soon as EMF Compare 1.0 is released.