we are currently making our code base ready for Eclipse 4.2. As we are using EMF Compare we also want to make sure that our product works well with the EMF Compare release for 4.2.
On the EMF Compare project plan site I can find the information that obviously EMF Compare 1.3 will be the right release for Eclipse 4.2. Since we are also using the UML2 extension for EMF Compare I stumbled upon bug #370710 and Comment #3:
The Juno release for EMF compare is the 2.0 and is going to change pretty much
every API we have right now.
What kind of API are you expecting to do your work ? In which kind of use case
On the other hand the 1.3 release (just branched) is targeting Indigo and we
can't build an 1.3 release both compatible with Juno and Indigo because of the
renaming which happened in Papyrus.
Now I'm wondering which branch in the EMF Compare git repository is the correct base for 4.2: 1.3 or master? If I assume that the master branch will make into 4.2 I have some questions:
When will the master branch be consumable to work with this branch? According to a posting on the emf-dev mailing list this will not be before feature freeze which means EMF Compare M7. Is that realistic? This is especially important regarding the UML2 extension for EMF Compare.
I looked for classes like the old MergeService but I couldn't find functionality or tests concerning the merge feature. Did I miss something or is the restructuring not completed yet?
Am I right that there are no other heuristics than XMI id based matching anymore?
Our plans for Juno were not totally finalized at the time, and we went back on some decisions as we thought we decided on a 2.0 on too short a notice. The juno release of EMF Compare will be the 1.3, as advertised on the plan. This 1.3 release is mostly untouched with very few bug fixes. It lies on the "1.3" branch of the git repository.
However, a "2.0" release will follow very shortly, out of the Eclipse release train but really close to it. This release is what will change most of our APIs (as well as the metamodels EMF Compare uses as its core). That is what lies on the "master" branch of the git repository, and where our current development effort focuses.
1. The UML2 extension for EMF Compare will be upgraded for the 2.0 stream when the core is finalized (sometime during June). Note that if you are using it as an API, you too will have to update your code if you wish to adopt the 2.0 as a base. If you only consume it from an user perspective (comparing UML models through the "compare with" menu with no custom code), the change should be transparent.
2. The merge process has yet to be restructured to cope with the new core. It is one of the last features we have to rethink. MatchService and DiffService have both been merged in the simpler "EMFCompare" class. MergeService will most likely undergo the same simplification. This is for the 2.0 stream though. 1.3 remains untouched on these entry points.
3. The scope of 2.0 is to only provide a fully functional diff and merge process for ID-based comparisons. Heuristics will be added back with 2.1 which should closely follow 2.0 as it will only impact the matching process of EMF Compare.
I hope this clarifies the current efforts a little. Do not hesitate if I am not clear on certain issues.
thanks for your clear statement! So we will use the 1.3 stream of EMF Compare. I only have one question left: The UML2 extension still has compile errors due to incompatibility of MDT UML2 4.0. Will these issues be fixed on the 1.3 stream?
The UML2 extension has now been fixed on 1.3, this was an oversight (we were missing one commit) that we had yet to detect since we did not have a build . Do note that the UML2 and Papyrus extension of this new 1.3 build will only be compatible with the UML2 and Papyrus version for Juno.
The 1.3.1M7 build will be available in the hours to come (we only need hudson to finish its job) on the 1.3 milestones update site.