|
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/
|
