EMF Compare/Release Review/3.0.0
- 1 Luna Release Review - EMF Compare 3.0
- 1.1 New & Noteworthy
- 1.2 Quality of APIs
- 1.3 End of Life Issues
- 1.4 Commiter Diversity
- 1.5 IP Issues
- 1.6 Non-Code Aspects
- 1.7 APIs
- 1.8 Documentation
- 1.9 Bugzilla
- 1.10 Tool usability
- 1.11 Standards
- 1.12 UI Usability
- 1.13 Communities
- 1.14 Committer Changes
- 1.15 Schedule
- 1.16 Project Plan
- 1.17 Legal Notices
Luna Release Review - EMF Compare 3.0
Laurent Goubet (email@example.com)
Release Review : May 2014
Communication Channel : eclipse.modeling.emf newsgroup
Process Documentation : http://www.eclipse.org/projects/dev_process/development_process.php
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.
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|
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.
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.
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.
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.
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
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
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.
1103 unit tests launched on every build.
Code coverage is about 70% of the core.
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.
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.
All of the documentation for EMF Compare is available online at . It will be completed and extended with tutorials as the version matures.
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.
Localization : integrated into Babel
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.
EMF Compare is conforming to the Eclipse user interface guidelines.
Talks have been given on the following events:
- Eclipse Con Europe 2013
- Eclipse Con US 2014
Talks have been submitted for the following events: Eclipse Con France 2014:
- 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.
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).
EMF Compare 3.0 follows the Kepler Release train, on +2 offsets.
The EMF Compare 3.0 project plan is available at https://projects.eclipse.org/projects/modeling.emfcompare/releases/3.0.0/plan
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.