Issues with Xtext and Epsilon [message #1842280] |
Tue, 15 June 2021 11:36  |
Eclipse User |
|
|
|
Hi all,
I have an Xtext grammar and a metamodel in ecore for which I am writing transformations in Epsilon. However, I am having issues with one of the transformations. I spoke to the people from Epsilon, and according to them, with respect to emf everything is fine, but the issue might be with Xtext.
This is the link to the thread I created on Epsilon, where I have also uploaded the files, which you can use to reproduce the issue, and the answer from them. https://www.eclipse.org/forums/index.php/t/1108216/
Can anyone please help with this?
Many thanks,
Tomas
|
|
|
|
Re: Issues with Xtext and Epsilon [message #1842282 is a reply to message #1842281] |
Tue, 15 June 2021 12:06   |
Eclipse User |
|
|
|
Hi
It looks rather unlikely to be to do with Xtext, though by using Xtext you perhaps have an autogenerated rather than manually designed metamodel; not a practice I recommend particularly if you need it for ongoing transformation work. Just possibly the unusual location causes a difficulty.
Your actual problem with paths reminds me of a bug I had with a linked list, for which EMF does not support a unit list out of the box. See [1]. You, or your tooling, must set the XMLResource.OPTION_DEFER_IDREF_RESOLUTION load option.
Regards
Ed Willink
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=499442
|
|
|
Re: Issues with Xtext and Epsilon [message #1842283 is a reply to message #1842282] |
Tue, 15 June 2021 12:17   |
Eclipse User |
|
|
|
Hi Ed,
Thanks for the answer. Yes they look very similar. If possible can you please guide me where I can find this option so I can give it a try and see if it resolves my issue? And should it be on the source (ecore) or target (text) metamodel?
Thanks in advance!
Best,
Tomas
[Updated on: Tue, 15 June 2021 12:23] by Moderator Report message to a moderator
|
|
|
|
|
Re: Issues with Xtext and Epsilon [message #1842292 is a reply to message #1842288] |
Tue, 15 June 2021 15:41   |
Eclipse User |
|
|
|
Hi
No it is a bug in EMF that EMF chooses not to fix, so every application has to encounter diagnose and workaround for itself. QVTo hasn't yet (Epsilon probably hasn't either.) If you are using the standard QVTo launch, you are stuck, unless you fix the bug yourself. If you are using a programmatic launch you have an opportunity to tweak your ResourceSet.
Since the bug only occurs for limited case of a self-reference that seems to be unique to a unit list, you have the easy workaround of avoiding unit lists, at least while testing.
NB. Just because this reminds me of the bug does not mean it is the bug. You should confirm before following my leap to a possibility.
Regards
Ed Willink
|
|
|
Re: Issues with Xtext and Epsilon [message #1842296 is a reply to message #1842292] |
Tue, 15 June 2021 20:25   |
Eclipse User |
|
|
|
Hi guys,
Ok I tried something else. So instead of using the ecore model generated by xtext as target for the transformation, I created a new ecore modelling project where I copy pasted the emfatic source of the ecore model generated by xtext (so the ecore model generated by xtext and the one I created are exactly the same). I used this new ecore model as target for the transformations.
Now it works! So apparently, it does not work when I use as target the model generated by xtext, but it works if I use as target a model that is exactly the same as the one generated by Xtext, but it is created through an ecore modelling project. Any ideas on that?
Many thanks,
Toma
|
|
|
|
Re: Issues with Xtext and Epsilon [message #1842306 is a reply to message #1842304] |
Wed, 16 June 2021 06:17   |
Eclipse User |
|
|
|
Hi
If you have one good *.ecore and one bad 'identical' *.ecore, then it is a simple matter of comparing the differences and removing those that do not matter until you are left with the one that does.
xsi:schemaLocation might be the first thing to look at. Tooling might have trouble accessing it in the non-standard location that Xtext puts it.
Since you do not share either *.ecore with us, you make it very hard to provide any further help.
Regards
Ed Willink
|
|
|
Re: Issues with Xtext and Epsilon [message #1842346 is a reply to message #1842306] |
Wed, 16 June 2021 19:40   |
Eclipse User |
|
|
|
Hello,
So I am sharing the working and not working projects.
Notworking.zip contains two folders:
---FirstInstance - Contains the Xtext grammar and the generated ecore model that is used as target for the transformations.
--SecondInstance - Contains the ecore model that is used as source for the transformation, the models and the transformation itself.
If you run it you will encounter the same issue as I was mentioning.
__________________________________________________________________
Working.zip contains three folders
---Hepra - Contains the ecore model created by copying the emfatic of the ecore model generated by Xtext (identical to it) - corresponding to the FirstInstance in Notworking.zip
---Forest - Contains the ecore model that is used as source for the transformation and the transformation itself - - corresponding to the SecondInstance in Notworking.zip
---DimitrisTransformation - Contains the transformations and the models - corresponding to the SecondInstance in Notworking.zip
_________________________________________________________________
Thank you!
Best,
Tomas
|
|
|
Re: Issues with Xtext and Epsilon [message #1842354 is a reply to message #1842346] |
Thu, 17 June 2021 03:57   |
Eclipse User |
|
|
|
hi, unfortunately i cannot reproduce your NPE,
i am getting
org.xtext.example.textual.textual.impl.PathImpl
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@33:0-33:26)
at (unknown@0:0-0:0)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@9:12-9:30)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@9:0-9:32)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@9:0-9:32)
at (unknown@0:0-0:0)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@4:0-104:1)
05:52:03.856 [Worker-0: Updating Maven Dependencies] DEBUG org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager - Refreshed: [L/x/pom.xml, L/DimitrisTransformations/pom.xml]
org.xtext.example.textual.textual.impl.PathImpl
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@33:0-33:26)
at (unknown@0:0-0:0)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@9:12-9:30)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@9:0-9:32)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@9:0-9:32)
at (unknown@0:0-0:0)
at (/home/dietrich/eclipse-workspaces/lsp2222222222/DimitrisTransformations/transform.etl@4:0-104:1)
at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:118)
at org.eclipse.emf.common.util.BasicEList.addAllUnique(BasicEList.java:507)
at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddAllUnique(NotifyingListImpl.java:500)
at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:440)
at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addAllUnique(NotifyingListImpl.java:400)
at org.eclipse.emf.common.util.AbstractEList.addAll(AbstractEList.java:368)
at org.eclipse.epsilon.emc.emf.EmfPropertySetter.copyCollectionValues(EmfPropertySetter.java:75)
at org.eclipse.epsilon.emc.emf.EmfPropertySetter.invoke(EmfPropertySetter.java:61)
at org.eclipse.epsilon.eol.dom.AssignmentStatement.execute(AssignmentStatement.java:77)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.executeImpl(ExecutorFactory.java:204)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.execute(ExecutorFactory.java:233)
at org.eclipse.epsilon.eol.dom.StatementBlock.execute(StatementBlock.java:66)
at org.eclipse.epsilon.eol.dom.StatementBlock.execute(StatementBlock.java:1)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.executeImpl(ExecutorFactory.java:204)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.execute(ExecutorFactory.java:233)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.executeBlockOrExpressionAst(ExecutableBlock.java:103)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.executeBody(ExecutableBlock.java:164)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.execute(ExecutableBlock.java:121)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.execute(ExecutableBlock.java:168)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.execute(ExecutableBlock.java:92)
at org.eclipse.epsilon.etl.dom.TransformationRule.executeSuperRulesAndBody(TransformationRule.java:232)
at org.eclipse.epsilon.etl.dom.TransformationRule.transform(TransformationRule.java:188)
at org.eclipse.epsilon.etl.strategy.FastTransformationStrategy.executeTransformations(FastTransformationStrategy.java:115)
at org.eclipse.epsilon.etl.strategy.FastTransformationStrategy.getEquivalents(FastTransformationStrategy.java:41)
at org.eclipse.epsilon.etl.strategy.ITransformationStrategy.getEquivalent(ITransformationStrategy.java:38)
at org.eclipse.epsilon.etl.execute.operations.EquivalentOperation.executeImpl(EquivalentOperation.java:26)
at org.eclipse.epsilon.etl.execute.operations.AbstractEquivalentOperation.execute(AbstractEquivalentOperation.java:48)
at org.eclipse.epsilon.etl.execute.operations.EquivalentOperation.execute(EquivalentOperation.java:1)
at org.eclipse.epsilon.eol.dom.OperationCallExpression.execute(OperationCallExpression.java:187)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.executeImpl(ExecutorFactory.java:204)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.execute(ExecutorFactory.java:233)
at org.eclipse.epsilon.eol.dom.OperationCallExpression.execute(OperationCallExpression.java:149)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.executeImpl(ExecutorFactory.java:204)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.execute(ExecutorFactory.java:233)
at org.eclipse.epsilon.eol.dom.ExpressionStatement.execute(ExpressionStatement.java:32)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.executeImpl(ExecutorFactory.java:204)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.execute(ExecutorFactory.java:233)
at org.eclipse.epsilon.eol.dom.StatementBlock.execute(StatementBlock.java:66)
at org.eclipse.epsilon.eol.dom.StatementBlock.execute(StatementBlock.java:1)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.executeImpl(ExecutorFactory.java:204)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.execute(ExecutorFactory.java:233)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.executeBlockOrExpressionAst(ExecutableBlock.java:103)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.executeBody(ExecutableBlock.java:164)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.execute(ExecutableBlock.java:121)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.execute(ExecutableBlock.java:168)
at org.eclipse.epsilon.eol.dom.ExecutableBlock.execute(ExecutableBlock.java:92)
at org.eclipse.epsilon.etl.dom.TransformationRule.executeSuperRulesAndBody(TransformationRule.java:232)
at org.eclipse.epsilon.etl.dom.TransformationRule.transform(TransformationRule.java:188)
at org.eclipse.epsilon.etl.strategy.FastTransformationStrategy.executeTransformations(FastTransformationStrategy.java:115)
at org.eclipse.epsilon.etl.strategy.FastTransformationStrategy.transformModels(FastTransformationStrategy.java:107)
at org.eclipse.epsilon.etl.EtlModule.processRules(EtlModule.java:139)
at org.eclipse.epsilon.erl.ErlModule.executeImpl(ErlModule.java:174)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.executeImpl(ExecutorFactory.java:207)
at org.eclipse.epsilon.eol.execute.ExecutorFactory.execute(ExecutorFactory.java:233)
at org.eclipse.epsilon.eol.EolModule.execute(EolModule.java:434)
at org.eclipse.epsilon.eol.dt.launching.EpsilonLaunchConfigurationDelegate.launch(EpsilonLaunchConfigurationDelegate.java:111)
at org.eclipse.epsilon.eol.dt.launching.EpsilonLaunchConfigurationDelegate.launch(EpsilonLaunchConfigurationDelegate.java:69)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:803)
at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:716)
at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:1021)
at org.eclipse.debug.internal.ui.DebugUIPlugin$2.run(DebugUIPlugin.java:1224)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.ArrayStoreException: org.xtext.example.textual.textual.impl.PathImpl
... 62 more
which hints a problem with your transformation
where is your NPE?
|
|
|
|
Re: Issues with Xtext and Epsilon [message #1842360 is a reply to message #1842354] |
Thu, 17 June 2021 07:16   |
Eclipse User |
|
|
|
Hi Christian,
Yes I get the same error with the non working example, but I also get a pop up for the npe. I spoke to the people from Epsilon and they said that the transformations were fine.
Regarding, the working example, I just retried it, and it does work on my side :/
Best,
Tomas
|
|
|
|
Re: Issues with Xtext and Epsilon [message #1842366 is a reply to message #1842360] |
Thu, 17 June 2021 08:20   |
Eclipse User |
|
|
|
Hi
When I import the Notworking.zip projects into a Windows Eclipse (I've no idea what happens to the MACOS bits) and I run Notworking\SecondInstance\DimitrisTransformations\transform.launch I get an NPE
java.lang.NullPointerExceptionjava.lang.NullPointerExceptionType 'Source!Forest' not found
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@5:13-5:26)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@100:13-100:24)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@83:13-83:24)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@65:13-65:24)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@56:13-56:31)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@46:13-46:30)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@15:13-15:29)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@5:13-5:26)
at (E:\Development\Rusa\Workspace\Notworking.zip_expanded\Notworking\SecondInstance\DimitrisTransformations\transform.etl@4:0-104:1)
But this looks like a 'releng' bug. When I view the launch it has some very smelly content such as
<listAttribute key="models">
<listEntry value="aliases=
reuseUnmodifiedFileBasedMetamodels=true
modelFile=/DimitrisTransformations/forestmodel.model
metamodelUri=http\://www.example.org/forest
concurrent=false
type=EMF
readOnLoad=true
storeOnDisposal=false
expand=true
fileBasedMetamodelUri=
metamodelFile=
cached=true
name=Source
modelUri=platform\:/resource/DimitrisTransformations/forestmodel.model
isMetamodelFileBased=false"/>
<listEntry value="aliases=
reuseUnmodifiedFileBasedMetamodels=true
modelFile=/DimitrisTransformations/forestmodel.textual
metamodelUri=http\://www.xtext.org/example/textual/Textual
concurrent=false
type=EMF
readOnLoad=false
storeOnDisposal=true
expand=true
fileBasedMetamodelUri=
metamodelFile=
cached=true
name=Target
modelUri=platform\:/resource/DimitrisTransformations/forestmodel.textual
isMetamodelFileBased=false"/>
</listAttribute>
I do not recall seeing ":" backslashed before, and it should not be necessary within "".
When I view the launch in the Run Configurations editor there are no models so it would appear that what I observe as smelly is silently ignored so that all the launch knows about is transform.etl and since Epsilon/this example does not use an import statement it is hardly surprising that Source!Forest is not found.
I suspect that all your problems are due to failure to configure Epsilon to use the correct Xtext model.
I suggested earlier that you need to ensure that xsi:schemaLocation is suitable.
If I try to open forestmodel.model with the Sample Ecore Model Editor I get package not found failures demonstrating that forestmodel.model is not fit for generic EMF-based purpose. Instead you rely on xmlns:forest="http://www.example.org/forest" having a definition, which it doesn't until you run in a nested Eclipse. That is what xsi:schemaLocation solves.
If you open forest.ecore with the Sample Ecore Editor then use the menu to create a Dynamic Instance of Forest the resulting xmi is:
<?xml version="1.0" encoding="UTF-8"?>
<forest:Forest xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:forest="http://www.example.org/forest" xsi:schemaLocation="http://www.example.org/forest forest.ecore"/>
This demonstrates the xsi:schemaLocation declaration that enables regular EMF-based tooling to locate the metamodel in a non-nested Eclipse and without non-standard tweaks to the 'immutable' global EPackage.Registry.
Again your problems with two versions of the same metamodel may be due to inconsistent non-standard EPackage.Registry tweaking with open editors failing to track your tweaking.
Regards
Ed Willink
|
|
|
|
Re: Issues with Xtext and Epsilon [message #1842779 is a reply to message #1842368] |
Thu, 01 July 2021 09:44   |
Eclipse User |
|
|
|
Hi guys,
I have tried to find a solution to it but nothing so far. The same problem persists when one of the metamodels is generated from Xtext. I tried it again with the zip files that I sent you and one of them works (both metamodels created with EMF) and the other doesn't (one metamodel with EMF and the other with Xtext). Try the one that works first.
Moreover, eplison has a thing called epsilon playground where you put the emfatic source of both metamodels, create a model, write the transformations and it generated the target model. There it works too, but whenever I try it with Xtext I get the same issue.
Attached I am also sending the links for two recordings of both examples, for you to see what happens on my side.
NotWorking: https://streamable.com/hv5ji5
Working: https://streamable.com/zu1ydw
I would deeply appreciate your help because I am stuck with the entire transformations just because of this specific case.
Many thanks,
Tomas
|
|
|
Re: Issues with Xtext and Epsilon [message #1842804 is a reply to message #1842779] |
Thu, 01 July 2021 17:28   |
Eclipse User |
|
|
|
Hi
I finally managed to get something to reproduce the ArrayStaoreException.
It seems to be a simple case of bad transformation.
"t.initialpath ::= s.paths;"
should be reported as a type error by the Epsilon Editor to avoid an obscure execution experience as an incompatible path is assigned to an InitialPath collection.
Regards
Ed Willink
|
|
|
|
Re: Issues with Xtext and Epsilon [message #1842816 is a reply to message #1842805] |
Fri, 02 July 2021 06:28   |
Eclipse User |
|
|
|
Hi
Why does it sometimes work?
Quote:I finally managed to get something to reproduce the ArrayStoreException.
I had to open Forest in the first instance and use the genmodel so that http://www.example.org/forest had a regular definition in the second instance. genmodel had not been used in your NotWorking.zip.
Once a genmodel is in use you are using static EMF and strong run-time typing that causes Java to barf on the bad assignment.
I suspect that you are using dynamic EMF when it 'works' and so you benefit from inadequate run-time type checking by Epsilon that lets the bad assignment slide.
I'm not clear how you get dynamic EMF to work since in the absence of an xsi:schemaLocation there is no definition of http://www.example.org/forest. However I am aware that Epsilon has some irregular abilities to define metamodels that you may have used. I am also aware that Xtext has an index-the-world functionality that just possibly might discover http://www.example.org/forest and so 'publish' it. However while I dislike index-the-world in principle, I have not seen this kind of publication in practice.
Regards
Ed Willink
|
|
|
Re: Issues with Xtext and Epsilon [message #1842820 is a reply to message #1842816] |
Fri, 02 July 2021 07:21   |
Eclipse User |
|
|
|
Hi Ed,
Thanks for your feedback. Is there any way to get past this? Cause it is really weird to be in this situation wherein one scenario it works and in the other doesn't with the same transformations.
Furthermore, the concepts and relations in the metamodel are such that one path in the source metamodel should be transformed into three different type of paths in the target metamodel depending on the guard.
Moreover from a discussion with the guys from Epsilon I had the following feedback.
Quote:
If you replace "t.initialpath ::= s.paths;" with "t.initialpath.add(new Target!Path);" the problem still persists so it seems to be related to the type of the element you're trying to add (Path). This is perfectly fine EMF-wise but Xtext doesn't seem to like it for some reason.
And after letting them know of your last message they mentioned that:
Quote:
Epsilon relies on the underlying modelling framework (EMF/Xtext) for run-time type checking so it's unlikely that it is the source of the problem
Many thanks,
Tomas
[Updated on: Fri, 02 July 2021 08:00] by Moderator Report message to a moderator
|
|
|
Re: Issues with Xtext and Epsilon [message #1842827 is a reply to message #1842820] |
Fri, 02 July 2021 09:30  |
Eclipse User |
|
|
|
Hi
Yes. It is very easy to get past this. Fix the bad line in the transformation.
Epsilon's reliance on the underlying tooling to detect errors is like going back to the old days when you developed programs with a dumb editor and only got messages much later. Epsilon should type check transformations. That is an Epsilon not Xtext bug.
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.26993 seconds