Community
Participate
Working Groups
EcoreIDSimilarityChecker and XMIIDSimilarityChecker are based on proper initialization to return correct results within their isSimilar and absoluteMetric methods. That is, these methods can only match EObjects properly, if they have been initialized with the containing resource (or an ancestor object). When comparing two resources within GenericMatchEngine, the checker is thus initialized within the doMatch method, passing in the two local resources that are to be compared. This is pretty fine when computing matches for the EObject contained in these resources. However, it does not suffice when computing scope-external reference within GenericMatchEngine#recursiveMappings. That is, all EObjects contained within current1ScopeExternalReferences and current2ScopeExternalReferences, which are not directly contained in the two compared resources, will not be matched properly by the delegating call to the checker if ID or XMI_ID based comparison is used. As such, a lot of dummy changes are reported for those references to outside the compared resources in this case. To fix this issue, the checker could alternatively be initialized with the containing resource sets of the two resources to be compared.
I am investigating features of EMF Compare to use it in my works. Thank you the work done in this project and for good developer guides. However, I faced the following problem: Create a UML model, create a Class in it. Apply any profile and stereotype. Say, Standard profile and Standard::Metaclass stereotype to the root package and the Class respectively. Make any other change - e.g. add a new elemene. Compare the model in local history - the following diff will always be displayed in addition to actual changes: -"standard has been added to reference references: EObject in UML" -"standard has been removed from reference references: EObject in UML" I tries both comparison options - "Selected resource only" and "Complete resource set" As I understand I have the same problem as described in this bug. If so, could you tell me what are chances that this bug will be fixed soon? Possibility to correctly process models contaning stereotypes is crucial for me. Thank you.
Hi Tatiana, Our working time on EMF Compare is pretty scarce, and fixing this bug isn't a priority for us. If it is critical to you, you can always write a patch according to Alexander's comment in order to fix the issue and attach it to this bug; we'll be more than happy to review and commit the patch for the next build.
Alexander, Could you provide us with a small unit test (or minimal ecore files with which I can reproduce this) so that I can debug and see (and fix :p) what's happening here? Tatiana, we now provide an UML-specific comparison engine that should take care of the issue you describe here.
The match, diff and merge process have seen a great deal of improvement in the past weeks, with the addition of unit tests for most of the different use cases (one use case = one possible "diff" between models) we could think of. The particular issue of dummy changes with scope-external EObjects is one of the things that has been tested and fixed; without further info about the models on which you had comparison problems, I'll assume the problem is resolved. These changes have been pushed on both master and the 1.2 maintenance stream. They are available in the builds - 1.2 integration : I201108090404 - 1.3 integration : I201108090415
