Hi Steffen,
based on the information that the "First" rule cannot be matched
while the "Third" rule can, my feeling is that the multi-nodes are
not the root cause of the problem: If the LHS of the kernel rule
(the part without the multi-elements) can be matched, then there is
a match for the entire rule as well, since matching the multi-rule
is optional.
Of course, there is a simple way to be sure it's indeed not the
multi-nodes: you could remove them from the rule and see if the
problem still occurs.
BTW, I'm not sure about the actual purpose of the multi-nodes in the
"First" and "Third" rule. Since the multi-rules of these rules don't
specify any changes, they shouldn't have any effect on rule
applications anyways.
Best regards,
Daniel
Am 23.06.2017 um 17:53 schrieb Steffen
Zschaler:
Hi Daniel,
Thanks for your comments on Kinga's question. Can I just
clarify your thoughts on the following question:
We were unsure whether this was something to do with us
misunderstanding something about how Henshin works (in
particular, in relation to multi-nodes, which were present in
the rules where the problem first occurred) or whether this
might actually be a bug in Henshin. What is your view on this?
Many thanks,
Steffen
On 23/06/2017 13:09, Bojarczuk, Kinga
wrote:
|
This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing |
Feedback |
Yes that's correct and I was thinking the same that it
seems odd. I can use rule 'Third' but I'd still like to
know why the other one doesn't work so if you come up with
anything please let me know.
Thank you,
Kinga
So your rule "Third" works on set-up (2), while rule
"First" does not - OK, that's really odd, and I don't have
any further ideas for the moment.
For all practical purposes, I can encourage you to simply
use rule "Third" instead "First": Removing an object from
its container object basically has the same effect as
deleting it altogether. (One needs to be careful with other
elements referencing the element-to-deleted, though.)
Best regards,
Daniel
Am 23.06.2017 um 13:48 schrieb
Bojarczuk, Kinga:
Yes you are correct but again as I said if you run
the 'Third' rule on the behavior file it accepts
it/finds a match so it does accept two layers of
cross-referencing in the interpreter wizard. And I
have applied the rule programmatically(as I said in
the previous email) and it doesn't work either but I
am 100% sure the set up is correct because I have been
working on other rules that work and they run just
fine in both the wizard and through Java -> as does
rule 'Third'.
Hi Kinga,
to summarize, there are two different model set-ups:
(1) server2.gcs -> server2.ecore
(2) server3.behavior -> server2.gcs ->
server2.ecore
Using the interpreter wizard, your rule works when apply
it to (1), and does not work when you apply it to (2).
Right?
Then it could still be an issue with the interpreter
wizard, but a more subtle one: the wizard can deal with
one layer of cross-referencing, but not with two or more
ones.
Can you try the following: Apply the rule
programmatically to set-up (2). But before you apply the
rule, make sure to load all three models and add them to
the same input EGraph.
Best regards,
Daniel
Am 23.06.2017 um 13:29
schrieb Bojarczuk, Kinga:
I'm sorry I think
I'm just very bad at explaining and wasn't
precise enough. I've been running a few other
examples already and I run it through a Java
class as you said but the transformation wizard
still accepts them as there is a match so it
just doesn't change anything after it runs. I
didn't include it because the output doesn't
matter for me it's just finding a match that
matters so the transformation wizard is enough.
And the java class doesn't find a match either
because if it was there then 'apply
transformation' would work instead of giving an
error, it just wouldn't change anything as it
only makes changes in the behavior file.
So my problem is that the rule is correct but
for some reason running it from the behavior
file doesn't find a match (neither in editor
nor the Java class) but it should because it
exists and the connections ( :Behavior ->
:MetamodelGD -> :PackageGD) are correct
because as I said the 'Third' rule works. So my
problem is why doesn't it find a match for the
'First' rule -> deleting :EReference node
when running it on the behavior file while it
finds it when running on the ecore/gcs files
(through both transformation wizard and java).
I've enclosed a screenshot which shows a rule
that runs on server2.gcs(which references
server2.ecore) file and finds a match. But after
adding :Behavior node at the front and running
it on server3.behavior it doesn't find it
anymore -> which is my problem from the
beginning as it should find that match as it
does the same it just references it through the
behavior file so I don't understand why it
doesn't.
Thank you,
Kinga
Hi Kinga,
Am 23.06.2017 um 12:39
schrieb Bojarczuk, Kinga:
Sorry bad-wording by the code I just meant
running the transformation just by 'apply
transformation' on the files. I just want it
to find a match.
Ah, I see. Then the actual issue is as follows: The
transformation wizard (which is executed by "apply
transformation") currently does not account for
references between models. In other works, it only
supports "self-contained" models which do not depend
on other models. This could be considered a bug, so
I will create a corresponding entry in our BugZilla.
In the meantime, you can run the transformation
programmatically by using the API (see [1] for an
example). There, dealing with references between
models is simple: Just add all involved models to
the same input EGraph.
[1] http://git.eclipse.org/c/henshin/org.eclipse.emft.henshin.git/tree/plugins/org.eclipse.emf.henshin.examples/src/org/eclipse/emf/henshin/examples/bank/BankExample.java
I cannot anyhow specify that containment edge
between EReference and EPackage in the Henshin
editor, it doesnt let me connect them. And if
that was the problem then why does it find a
match in the ecore file but not in the
behavior file?
Indeed, I now notice that my earlier interpretation
was wrong: EReferences are contained in EClasses
(and not in than EPackages). So the rule as it is
should be correct.
Because my main problem is that it
works/finds a match when run on the
server2.ecore file but when adding a 'top
layer' to run it on server3.behavior :Behavior
-> :MetamodelGD - > :PackageGD it
doesn't find a match anymore but these only
provide the reference to the ecore file so it
doesn't make any sense.
Best regards,
Daniel
Hello Kina,
Am 23.06.2017 um
12:06 schrieb Bojarczuk, Kinga:
Hello,
I'm working on this project on e-motions
files so basically there's a .behavior
file which is linked to .gcs which is
linked to .ecore file and together they
represent a graph transformation system.
So what I'm trying to do is to delete
EReference from .ecore file between the
object that has some subclasses and
another object. (First rule in my henshin
file) This should find a match as it
exists in a server2.ecore file however for
some reason it doesn't.
To understand why the rule cannot be applied,
it's crucial to know that Henshin aims to ensure
that output models of a transformation are
well-formed: in particular, it aims to ensure
that rule applications never leave behind
"dangling edges". In your example rule, since
you do not specify the deletion of the
containment edge between the :EPackage and the
:EReference, this edge would be left behind as
dangling, so Henshin won't apply the rule.
To make the rule applicable, it should be
sufficient to specify the deletion of the
aforementioned containment edge. (Another option
is to the set the "checkDangling" attribute in
the rule to "false", however, in this case, you
may lose well-formedness guarantees.)
When I run the code straight on the
server2.ecore (by starting with EPackage
in my rule) file or server2.gcs (by
starting with MetamodelGD in my rule) file
it works and finds a match but when
running on server3.behavior file something
suddenly prevents it from finding a match
which is really weird as .behavior file
just provides a reference to the other
files so since it works when run straight
on them it should work on the the behavior
file as well.
I can't find the code you mention in these
statements. The zip file only contains the
models and Henshin files.
Best regards,
Daniel
The Second rule shows the solution that
we thought might work as Links in
.behavior file are linked to EReferences
so we thought this might prevent deleting
EReferences but it doesn't work either.
The Third rule shows something that works
but is a rather 'unclean solution' as it
only deletes all the edges and doesn't
actually delete the node.
So any idea why running my rule on
.behavior file suddenly prevents it from
finding a match? It seems really weird so
I'd appreciate some help. I've included a
zip file with my project.
Thank you,
Kinga
_______________________________________________
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
_______________________________________________
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
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://emea01.safelinks.protection.outlook.com/?url="">
--
Dr. rer. nat. Steffen Zschaler AHEA
Senior Lecturer
King's College London
Department of Informatics
Email szschaler@xxxxxxx
Phone +44 (020) 7848 1513
WWW http://www.steffen-zschaler.de/
_______________________________________________
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
|
