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
|
