Thanks Jens,
I have reproduced the behavior and can confirm that it shouldn't
appear. The only clue i see is the derived "namespace" reference,
although it really shouldn't make a difference.
I will give it a closer look tomorrow.
Regards,
Daniel
Am 16.09.2015 um 18:46 schrieb Jens Bürger:
Am 16.09.2015 um 18:41 schrieb Daniel Strüber:
Based on the screenshot, I assume that
this rule should do the job,
unless there is an additional edge in the input model not
considered by
the rule. Do you mind sending a minimal example?
No problem.
Regards,
Daniel
Am 16.09.2015 um 18:35 schrieb Jens Bürger:
Thanks for your quick reply,
I altered the rule as shown in the screenshot but it doesn't
help.
Jens
Am 16.09.2015 um 18:24 schrieb Daniel Strüber:
You're totally right, the containment
edge must be deleted (the
graphical editor does this by default, so I usually let it
do this piece
of thinking for me :)).
Technically, both directions should work, since both edges
are
EOpposites and thus EMF takes care of updating their
correspondence. For
the sake of clarity, I prefer modeling the containment edge,
"transition" (as opposed to the container edge,
"container"), since the
containment edge is a distinguished kind of edge and
highlighted as such
in the editor.
Regards,
Daniel
Am 16.09.2015 um 18:15 schrieb Jens Bürger:
Am 16.09.2015 um 17:57 schrieb
Daniel Strüber:
[…]
To get an intact rule, you have to
specify the container
node and the connecting containment edge as preserved
elements.
Are you sure that the connecting containment edge needs to
be
specified as preserving? Isn't that exactly a dangling
edge then?
However, I tried to model it as you suggested, but if I
try to specify
the "transition" as preserve, the diagram editor also sets
the
Transition node to preserve.
I'm not really sure what is the right direction for the
containment
edge. I tried both with the most obvious possibilities for
edge types
("container" for Transition->Region and "transition"
for
Region->Transition) but none of this worked so far.
Greetings,
Jens
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user
--
Dipl.-Inf. Daniel Strüber
Software Engineering Research Group
Philipps-Universität Marburg, Germany, Hans-Meerwein-Str., Room
05D12
Phone: +49-6421-28-21511
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user
--
Dipl.-Inf. Daniel Strüber
Software Engineering Research Group
Philipps-Universität Marburg, Germany, Hans-Meerwein-Str., Room 05D12
Phone: +49-6421-28-21511
|