| Simple SuperType Problem in Grammar - Cannot find compatible feature [message #1847866] |
Wed, 10 November 2021 14:50  |
Eclipse User |
|
|
|
I have two ecore models:
ModelA.ecore and ModelB.ecore
I'm trying to create a xtext grammar that handles both models.
ModelA's plugins all work perfectly. No issues.
ModelA has a Class called LibraryElement. That LibraryElement has attributes: vendor, library, name, version.
ModelB has a Class called YpxComponent -> LibraryElement. i.e. LibraryElement is a SuperType of YpxComponent.
All ecore stuff works in ModelB. I can generate the emf models no problem and without issue. All types and supertypes look exactly like I expect. All hyperlinking in editors take me to the correct Types in the correct probjects.
Harmony acheived! ... until I try to make a grammar.
My grammar has all the correct imports. i.e. all the modelA::stuff is appropriately referenced (in the xtext file and workflow) - xtext has already figured out the Class hierarchy from me telling it what packages to use and selecting an entry point.
BUT
My YpxComponent has the following grammar:
YpxComponent returns YpxComponent:
'YpxComponent'
id=ID0
'{'
'vendor' vendor=Name
'library' library=Name
'name' name=NMTOKEN
'version' version=NMTOKEN
The vendor, library, name, version are all provided by the LibraryElement, but every single one of them is reporting an error like this:
Cannot find compatible feature vendor in sealed EClass YpxComponent from imported package http://my_company/ypx_1685_2014: The type 'YpxComponent' does not have a feature 'vendor'.
YpxComponent _clearly_ has this feature (it's inherited from the SuperType) so I suspect Xtext is telling me thing else, but I've spent the entire day not understanding how to get past this.
I'm tried all the import "platform/resource" substitutions I've seen from Google searches and nothing works.
This is basic inheritance stuff, EMF isn't having any issues.
|
|
|
|
|
|
|
|
|
| Re: Simple SuperType Problem in Grammar - Cannot find compatible feature [message #1847895 is a reply to message #1847894] |
Thu, 11 November 2021 13:07  |
| Eclipse User |
|
|
|
Hi
For pure EMF usage,
http://www.accellera.org/XMLSchema/IPXACT/1685-2014 references the Java code of a model installed a plugin and registered by an extension point.
platform:/resource/com.ipxact_1685_2014/model/ipxact_1685_2014.ecore references the Ecore model stored as a file in a project using a direct reference to that file.
(Since the project may be under development there is no reason to expect the two references to locate equivalent metamodels. If both are accidentally used, metamodel schizophrenia results.)
This is simple and provided you only use one style, many EMF tools work. However it is not always natural; users instinctively, and guided by poor tutorials, try to import development models using nsURIs.It is not always convenient, particularly when genmodels are involved since they must use *.ecore/*.genmodel references. Various tools provide often inconsistent techniques for helpfully resolving 'the wrong variant'. Xtext's help comes in the form of an index that I endeavour to avoid since many years of experience have convinced me that this kind of help ultimately contributes to greater confusion.
I find that Xtext works consistently and well with platform:/... references to manually maintained *.ecore; you just need to set the "Package not imported through URI" preference to Ignore. But beware, if any of your metamodels refer to an nsURI anywhere, it all falls over rather obscurely in genmodel.
IIRC Xtext's autogenerated *.ecore flles have inappropriate references that cause problems if the metamodels are used by other EMF-based tools such as M2Ms that do not share Xtext's helpful indexing strategy.
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.04062 seconds
Home