Bugzilla – Full Text Bug Listing
| Summary: | DiffEpatchService handles MoveModelElement incorrectly | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMFCompare | Reporter: | Steffen Dienst <sdienst> | ||||
| Component: | Core | Assignee: | EMF Compare <emf.compare-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | laurent.goubet | ||||
| Version: | 1.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
EPatch has been deprecated in favor of MPatch as the commiter in charge of EPatch has dropped down working on EMF Compare. Consequently, this bug won't be fixed. |
Created attachment 171074 [details] JUnit 4 test case The creation of an EPatch fails, if a model element got moved between two differing EStructuralFeatures. The attached testcase contains a simple example: An element gets moved between two different containers. The MatchModel recognizes this move and DiffEpatchService#handleEleMove(MoveModelElement ele) gets called. This method tries to remove/add the element on either side, but uses a single EStructuralFeature for each. This fails in my case, as the containing feature is different. A solution seems to be to use both containing features for adding/removing the element? Sadly, my understanding of the inner workings of the DiffEpatchService is not up to par...