Skip to main content



      Home
Home » Modeling » Compare » Compare transformed XText models - orderings
Compare transformed XText models - orderings [message #1065507] Wed, 26 June 2013 04:31 Go to next message
Eclipse UserFriend
Hi!

I have an XText DSL with 2 models A and B, which are "equivalent" in the sense, that the objects specified in both models are the same but just in another order, e.g.

model A as textual representation:
Node n
Node m
Edge n -> m

model B as textual representation:
Edge n -> m
Node m
Node n

In both models the Nodes specify name attributes and Edge references to the Node objects. The Nodes are specified in a NodeList and the Edges are specified in an EdgeList.

I want to unit test both models on equivalence, thus parse them with XText and compare both created Resources with EMFCompare 2.

I read that orderings could be checked with either setting the "ordered" attribute in the meta-model to false or neglecting the MOVE DifferenceKind or creating another DiffEngine with a FeatureFilter
http://wiki.eclipse.org/EMF_Compare/Developer_Guide#Changing_the_FeatureFilter
(which somehow did not detect the orderings and still created Differences with MOVE DifferenceKind).

However, I could filter with MOVE DifferenceKind.

Now my problem are the references in "Edge n -> m":
In model A the "n" references to the FIRST node (in XMI: ref="//@nodesList.0) while in model B "n" references to the SECOND node (ref="//@nodeList.1).

In EMFCompare these difference are checked by CHANGE DifferenceKind as well as ADD and DELETE! Now I do not want to completely neglect references, I just want to check, if the references go to the equivalent object, which was moved!

Do you have any ideas, how I can achieve this?

Best regards,
Alex.
Re: Compare transformed XText models - orderings [message #1066343 is a reply to message #1065507] Tue, 02 July 2013 04:55 Go to previous message
Eclipse UserFriend
Alex,

The ordering on containment references is treated differently from the rest, mainly because of those "//@ref.0" URIs : they need to be detected to ensure a proper merge (since the URIs must change).

In your use case, if I understand correctly, there should be only one difference detected, a MOVE for either m or n corresponding to the reordering. I do not understand what your other differences are. What are the CHANGE, ADD and DELETE you see?

Laurent Goubet
Obeo
Previous Topic:CompareEditorInput
Next Topic:Missing sources on 2.1.0 release
Goto Forum:
  


Current Time: Sun Jul 13 19:00:23 EDT 2025

Powered by FUDForum. Page generated in 0.04002 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top