OK, thanks Kinga for trying out the version without the multi-nodes.
Some new insights: I was able to apply the "First" rule to the
behavior model, after I turned off the dangling-edges check by
disabling the "checkDangling" attribute of the rule.
This implies there are some references in the input graph that
become dangling if the "EReference" node is deleted. To check if
this is the case, I inspected server3.behavior and noticed that it
indeed has many references to EReferences from the server2.ecore
file.
So, it's indeed a feature rather than a bug: please see the
explanation regarding dangling edges in my very first e-mail.
Best regards,
Daniel
Am 23.06.2017 um 19:17 schrieb
Bojarczuk, Kinga:
I've sent a simplified
version of the rule we were working on to Daniel and the
multi nodes are not doing anything there, I should have
deleted them as well. The rule
does not work after deleting them
either so in this case they are definitely not the problem
and the problem is in that delete EReference node somewhere.
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
_______________________________________________
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
|
