Revision as of 10:31, 15 July 2014

Luna Release Review - EMF Compare 3.0

Laurent Goubet (laurent.goubet@obeo.fr)

Release Review : May 2014

Communication Channel : eclipse.modeling.emf newsgroup

Process Documentation : http://www.eclipse.org/projects/dev_process/development_process.php

Project Plan : https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.0.0/plan

New & Noteworthy

User experience overhaul

The EMF Compare Graphical User Interface (GUI) has been rethought in order to make the workflow easier for the user and reduce the possible confusion induced by the action placements.

Action placement

The first visible change is that we moved the "merge" actions from the bottom pane to the very top of the comparison editor. These actions react to and operate on selections in the top panel (the structural view of the differences), which was hard to understand when they were located just above the bottom panel of the editor (which displays the content of the compared versions). This move can be seen in the following two screenshots.

EMF Compare 2.1.0	EMF Compare 3.0.0

Impact preview

Also visible in the above two screenshots is the previsualization of the impacts of a merge operation. All differences linked in one way or another with the currently selected one are highlighted in a different color depending on how they are related. In the above example, we have selected the difference on Magazine that's been made on the right side : we added Periodical as a super-type. This conflict with the removal of Periodical from the left side, highlighted in a light-red color, and depends on the fact we actually added the Magazine Class in the right side before we could add a super-type to it (highlighted in a light-green color).

This previsualization depends on the direction we are expecting to merge the difference, visible as the leftmost button in the editor's toolbar :

For example, if we are going to merge the change to pages (we added the feature pages inside a new Class Magazine on the left side), we can actually do two actions on it. We can either copy the change from the left side to the right, thus adding the pages feature to the right version, or copy it from the right to the left, thus reverting the difference in the left model, deleting the pages feature from it. Both actions have consequences, but not the same in both directions.

If we copy from the left to the right side, what we want is to "add the pages feature to the Magazine class in the right version". However, Magazine is itself a new class, so adding a feature to it requires us to also merge the addition of the class. Thus, the addition of Magazine gets highlighted when we select this direction for previsualization.

On the contrary, if we decide that we want to copy this change from the right to the left, we actually want to reject the addition of the pages features. This makes the change of this feature's type to "EInt" obsolete as well since it was a requirement for it, much the same as the addition of the class Magazine is a requirement for the addition of the pages feature.

Progress feedback

We previously used a background job while executing the comparison, leaving the user with an empty comparison editor until we could display the final result. Though we still won't display a partial comparison during its computation, visual feedback is now provided to the user as the comparison progresses from within the comparison editor itself.

Textual fallback

A comparison failure would previously be unrecoverable, leaving the user with an unhelpful "error" editor and the errors logged in the Eclipse error log. A comparison failure will now be displayed within the editor itself, along with a textual comparison of the files.

Extensibility

The number of extension points available to customize the different aspects of EMF Compare has been greatly expanded, allowing users to override or customize all of the comparison phases as well as the user interface itself, contributing new filters, new grouping options, changing the displayed labels for the differences, or changing the displayed items altogether.

Quality of APIs

The component lead certifies that the requirements for Eclipse Quality APIs have been met for this release. All non-API code is in "internal" packages.

End of Life Issues

Though 3.0 is a major release, there are very few breakages as compared to last year's 2.1 version. The small number of API breaks are all localized in the UI code and not used as far as we know. The EMF Compare team will swiftly answer inquiries regarding these breakages on the official communication channels.

All mehods and classes that face deletion have been marked as deprecated with instructions on how to switch to the new behavior, and will stay in the code base until the next release.

Commiter Diversity

4 active commiters from Obeo

• Cédric Brun
• Laurent Goubet
• Mikaël Barbero (Project Lead)
• Axel Richard

1 inactive commiter from Itemis and 1 from Obeo

• Cédric Notot
• Patrick Könemann

IP Issues

The about files and use licenses are in place as per the Guidelines to Legal Documentation.

• CQ 5460 - Google Collections Version: 1.0 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5460
• CQ 6518 - Guava Version: 10.0.1 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=6518
• CQ 7056 - Guava Version: 11.0.2 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=7056

Large contributions have been made through individual CQs, which can all be consulted from https://dev.eclipse.org/ipzilla/buglist.cgi?component=modeling.emf.compare .

All other contributions (code, documentation, images, etc) have been committed by individuals who are either Members of the Foundation or have signed the appropriate Committer Agreement. In either case, these are individuals who have signed, and are abiding by, the Eclipse IP Policy. The other contributions of the IP log are not significant or are written 100% by employees of the same employer (Obeo) as the Submitting Committer (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf).

All contribution Questionnaires have been completed.

The "provider" field of each plugin is set to "Eclipse Modeling Project".

The "copyright" field of each plugin is set to the copyright owner.

Any third-party logos or trademarks included in the distribution (icons, logos, etc) have been licensed under the EPL.

The EMF Compare IP log is located at http://www.eclipse.org/projects/ip_log.php?projectid=modeling.emfcompare

Non-Code Aspects

Continuous Integration

Project is built from the EMF Compare HIPP through Tycho. A nightly is built once a day if the SCM polling sees a change from the last build.

Unit Tests

1103 unit tests launched on every build.

Code coverage is about 70% of the core.

Code Quality

Common formatter and compiler configuration used throughout the whole project's plug-ins.

Checkstyle activated on most distinct plug-ins.

Eclemma used on a regular basis to ensure and improve code coverage from the unit tests.

Yourkit java Profiler used on a regular basis to improved performances and avoid bottlenecks.

Findbugs launched on a regular basis to avoid detectable bugs.

Javadoc represents about 40% of the java source code.

An analysis of the code base is available on Ohloh.

APIs

Metamodel definitions and interfaces are considered APIs.

Commitment to provide stand-alone comparison feature (Jar that can be used without Eclipse with minimal to no dependencies towards eclipse core Jars).

Non-API classes are separated from the exposed API through an "internal" namespace.

Non-API packages are exported with an internal visibility so that they remain visible but with a discouraged access warning.

Documentation

All of the documentation for EMF Compare is available online at [1]. It will be completed and extended with tutorials as the version matures.

Bugzilla

Here is a snapshot taken on May the 16th of all bugs that have changed since release 2.0.0 (Juno). These figures are subject to change until the official release of 2.1.0 as the Team is currently in the process of fixing bugs.

Note that these are only the bugs that changed somehow in-between the two releases (2.1 and 3.0), reflecting the activity during Luna development. At the time of writing, there are 59 opened and 2 unconfirmed bugs against EMF Compare.

Tool usability

Localization : integrated into Babel

Standards

No standard exists concerning the model comparison, though EMF Compare works nicely with any standard-based metamodel.

Since the 1.2 release a specific support for the UML standard is included in EMF Compare. This is also included in the 3.* stream.

UI Usability

EMF Compare is conforming to the Eclipse user interface guidelines.

Communities

Talks have been given on the following events:

• Eclipse Con Europe 2013
  • EMF 'n' Compare rescue rangers
• Eclipse Con US 2014
  • EMF 'n' Compare rescue rangers

Talks have been submitted for the following events: Eclipse Con France 2014:

• EGit and EMF Compare, modeling in a team environment

Other medium:

• Activity on the newsgroups
  • eclipse.modeling.emf : 60 new threads on EMF Compare from June 2013 to May 2014
  • eclipse.tools.emf : 13 new threads on EMF Compare from June 2013 to May 2014
• About one update every two months on Planet Eclipse.

Committer Changes

There have been no changes in the list of commiters for this release, but the project lead has switched from Cédric Brun to Mikaël Barbero in November 2013 (https://dev.eclipse.org/mhonarc/lists/emf-dev/msg01677.html).

Schedule

EMF Compare 3.0 follows the Kepler Release train, on +2 offsets.

Project Plan

The EMF Compare 3.0 project plan is available at https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.0.0/plan

Legal Notices

Java and all Java-based trademarks are trademarks of Oracle, Inc. in the United States, other countries, or both.

UML and XMI are trademarks of the Object Management Group.

Other company, product, or service names may be trademarks or service marks of others.