-
Notifications
You must be signed in to change notification settings - Fork 96
-
Notifications
You must be signed in to change notification settings - Fork 96
Error loading Ecore GenModel in New Xtext Generator (2.10) #41
Comments
The upload failed. So here are the files again... |
similar problem when referencing "Genmodel.genmodel" and "Xtext.genmodel" |
i did some debugging on this. basically we have the eclass "eclassififer" twice. org.eclipse.emf.ecore.impl.EClassImpl@56d93692 (name: EClassifier) (instanceClassName: null) (abstract: true, interface: false) once coming from loading the genmodel. the other coming from the epackage registry (via XtextPackage) isnt the plan to fully ignore the global epackage registry? Using resourceSet registry. The registered Packages will not be registered in the global EPackage.Registry.INSTANCE! |
what are the URIs of the two EMF-Resources containing the |
@meysholdt thus if i do something like
it works but i dont know if this is a good idea |
actually it is not since it destroys inferred metamodels. (org.eclipse.xtext.xtext.generator.ecore.EMFGeneratorFragment2.getReferencedEPackages(List)) seems not to work plus tons of ther places there when generating testlanguages well the problem is that resourceSet.createResource(ecoreByNsUri) => [ only works once.not for multiple languages |
Hello, I encouter the same problem when trying to create the grammar of a DSL that imports Ecore. My language My grammar is:
I have the following error:
But in |
Does anyone know some kind of ETA for when this gets resolved? |
since nobody is working on this (no time, knowledge or budget) there is no ETA |
Hi I have a similar problem, just wondering if you managed to solve this problem. |
… of a reference cannot be resolved
The best way to fix the problem in the example project provided by @fkoenig is to open
with
The MyResourceSetInitializer.xtend
MyGeneratorModule.xtend
Then change the workflow file like this:
|
I prepared PR #325 to improve the situation by printing a more meaningful error message. Now instead of
you get
Apart from this improvement, I propose to close this issue. We could add more documentation on this topic to the website, but that should be handled in a separate issue in eclipse/xtext. |
here is another occurence of this. https://www.eclipse.org/forums/index.php/t/1086680/ in this case the ecore does not even use platform:/plugin @szarnekow do you have some ideas on this? |
TL;DR: Is there a way to get this to work for genmodels other than Ecore.genmodel? The fix given by @spoenemann above seems to not work for our situation. (That said, @spoenemann: thanks for providing such a well-fleshed-out fix description and explanation of the problem.) We're running into this issue with xtext 2.12.0, but with another genmodel than the Ecore one. We're using an externally provided metamodel (say, A.ecore) in one of our own metamodels (say, B.ecore). A.ecore is included in an Eclipse plugin (which is part of a feature), so referencing A.ecore by platform:/plugin URI makes sense. I tried using A.ecore's nsURI in B.ecore instead, as suggested by @spoenemann above. This works for B.ecore itself, but it doesn't combine properly with, say, As there is no nsURI for genmodels (afaik), I can't reference A.genmodel by nsURI. An alternative is removing the reference to A.genmodel from B.genmodel. This (logically) causes the EMF code generator to generate Java code for both A.ecore and B.ecore inside B's Eclipse project. That is not a viable option, as we want to use the Java implementation of A that's in the externally provided Eclipse plugin. |
Ususally you use referencedResource=„platform:/resource/xxxx/model/yyyy.genmodel“ in the language section of the workflow (+ maybe a uri mapping) => can you give more details what you do |
We do indeed use
However, during the execution of the workflow, we get the following output:
So the genmodel is succesfully registered, but then a second attempt, that tries to use a platform plugin uri, fails. After nsURI-ing/removing the platform plugin URIs from B.ecore/B.genmodel, the second attempt is no longer performed (but this is not an option). |
Update: our issue appears to be fixed by changing the dependency on A.genmodel in B.genmodel from a platform plugin URI to a platform resource URI. That is, we went from
to
With this change, the mwe2 workflow executes successfully, both in Eclipse and in our Maven/Tycho build. |
i still wonder if adding a uri mapping would have done the same |
what is the final solution please? |
There is none. Depends what you exactly do and what happens in your case |
can you help to find out how I can fix it please? I have implemented the solution suggested by spoenemann (specialize the Xtext generator by adding these two classes), this allows to generate xtext artifacts but the log still shows: |
Try to store Ecore.genmodel and add a uri mapping with the standalone setup from a |
@asiehsalehi any hints on how to reproduce your problem? |
I also encountered this problem while Migrating the Eclipse Xcore Project to the new Xtext Generator Workflow: #563042.
@merks: See the corresponding Gerrit change @cdietrich I was also wondering whether this configuration is supposed to also work with the new generator workflow out-of-the-box. |
No idea what you try to do |
Let me clarify this a little bit. Currently, the Xcore project uses the old Xtext generator workflow. Since this workflow is deprecated, I am trying to migrate the project to the new Xtext generator workflow. As a first step, I changed the GenerateXcore.mwe2 workflow file to use the new Xtext generator workflow ( As a second step, I tried to execute the updated After some research, I found out that the Xcore.xtext file uses an imported meta-model Changing that reference to The question is why any change on the |
@szarnekow Do you have any hints on this? |
I think the registerGeneratedEPackage was crucial in the old workflow for this setup to succeed. |
Adding the
solved the problem at the Xcore project. Thanks for the hints @cdietrich and @szarnekow ! |
I know, it's almost two years ago but I ran into the same issue and can confirm that I solved it using the uri mapping. Regards, |
Closed as per the last comment. |
I think I found a bug in the new Xtext Generator in Xtext 2.10.
The Generator tries to load an Ecore GenModel referred in the imported GenModel of my Grammar.
I Added projects with this error to this ticket.
My Grammar:
`// automatically generated by Xtext
grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals
import "http://www.example.org/testModel"
import "http://www.eclipse.org/emf/2002/Ecore" as ecore
Document returns Document:
{Document}
'Document'
name=ID
'{'
('pages' '{' pages+=Page ("," pages+=Page)* '}')?
'}';
Page returns Page:
{Page}
'Page'
name=ID
'{'
('attributes' '{' attributes+=Attribute ("," attributes+=Attribute)* '}')?
'}';
Attribute returns Attribute:
{Attribute}
'Attribute'
name=ID
'{'
('type' type=[ecore::EClassifier|ID])?
'}';`
Error:
The text was updated successfully, but these errors were encountered: