EMF Compare/Release Review/2.0.0
- 1 Juno Release Review - EMF Compare 1.3
- 1.1 Release Highlights
- 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
Juno Release Review - EMF Compare 1.3
Laurent Goubet (firstname.lastname@example.org)
Release Review : July 31, 2012
Communication Channel : eclipse.modeling.emf newsgroup
Process Documentation : http://www.eclipse.org/projects/dev_process/development_process.php
EMF Compare 2.0 is a full overhaul of the design, architecture and code of the project. It aims at providing the same functionality as 1.3 did while lifting the limitations that it presented.
New and noteworthy
The model that constitutes the core of the comparison process has been fully reworked. What was previously split in two (diff.ecore and match.ecore) has now been merged into a single "compare.ecore" which provides all of the core API for EMF Compare. Furthermore, the number of concepts defined by this core model has been drastically reduced as compared to the 1.* stream.
The API in general has been simplified to ease adoption and re-use of EMF Compare in other projects. For example, programmatically launching a comparison can now be done through a single entry point instead of the previous minimum of two.
Do note that the general process of EMF Compare has not been altered : it is still separated into isolated phases. Matching the elements, computing the differences between matched elements, then merging the changes from one side to the other. However, the differencing process itself has been further divided into customizable units : computing the differences, computing the requirements between distinct differences, computing the conflicts between differences...
Though EMF Compare was already useable in standalone environments, this has been improved further such that the core of EMF Compare is now only comprised of a single plugin that only depends on a very limited set of other plugins.
EMF Compare 2.0 provides the mandatory architecture and API for the project to handle large input models. Though 2.0 only provides a default scope which ends up in the same functionality as the 1.3 release (loading everything in memory and comparing the input models as a whole), this scope can (and will be) used by the subsequent version of EMF Compare, 2.1, to be able to handle extremely large input models.
EMF Compare 2.0 is much more integrated with the Eclipse Compare UI than the 1.* stream ever was. EMF Compare now properly integrates with folder comparisons, the icons are now the standard Eclipse Compare ones, we're reusing the standard Eclipse Compare viewers instead of custom ones...
Some performance bottlenecks of EMF Compare 1.3 have been identified yet cannot be solved without fully re-thinking the comparison process. EMF Compare 2.0 fixes these problems and is generally faster than the 1.* stream even using the default scoping mechanism.
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
EMF Compare 2.0 being a full overhaul of the project, its API is not compatible with its previous 1.* versions. A migration guide will be provided in order to ease the adoption effort to this new version.
All API that was provided by the 1.* stream has been deprecated with the 1.3 release (see the 1.3 End Of Life Issues) and is no longer available in its previously existing state.
The extension points proposed by the 1.3 release have not been ported yet to the 2.* stream, but should be pressent in the subsequent 2.1 release.
4 active commiters from Obeo
- Cédric Brun (Project Lead)
- Cédric Notot
- Laurent Goubet
- Mikaël Barbero
1 inactive commiter from Itemis
- 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
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.emf.compare
Project is built from the Eclipse hudson instance through Tycho. A nightly is built once a day if the SCM polling sees a change from the last build.
349 unit tests launched on every build.
Code coverage is about 80% of the core.
Common formatter and compiler configuration used throughout the whole project's plug-ins.
Checkstyle activated on each distinct plug-in.
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 50% of the java source code.
An analysis of the code base page 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.
Documentation is not up-to-date yet.
No Bugzilla closed specifically for this release, however, all bugs closed for 1.3.0 had their fix up-ported to 2.0 so that no regression would be observed on the up-ported features and functionalities. See the Bugzilla snapshot for the 1.3 release.
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 2.0 release.
However, the 1.3 release saw the inclusion of a specific support for the SYSML standard comparison. This has not been up-ported to 2.0 yet.
EMF Compare is conforming to the Eclipse user interface guidelines.
Talks have been given on the following events: Eclipse Con Europe 2011 :
- What every Eclipse Developer should know about EMF
- What the heck are logical models?
- EMFCompare improvements: fulfilling requirements of the Modeling Platform Working Group
Talks have been submitted for the following events: Eclipse Con Europe 2012:
- Activity on the EMF newsgroup (eclipse.modeling.emf): 29 new threads on EMF Compare from June 2011 to May 2012
- About one update every two months on Planet Eclipse.
EMF Compare 2.0 Release Plan
M6 03/21/2012 M7 05/04/2012 RC1 08/03/2012 RC2 08/10/2012 Final 08/15/2012
The EMF Compare 2.0 project plan is available at http://www.eclipse.org/modeling/emf/compare/project-info/plan-2_0.xml
Java and all Java-based trademarks are trademarks of Oracle, Inc. in the United States, other countries, or both.
UML, SYSML, OMG, EMOF, OCL and XMI are trademarks of the Object Management Group.
Other company, product, or service names may be trademarks or service marks of others.