[Acceleo] Cannot access EClass objects declared in a referenced .ecore file [message #1698102] |
Thu, 11 June 2015 05:21  |
Eclipse User |
|
|
|
Hi everyone,
I am currently working on an Acceleo project based on the Ecore metamodel. The main .ecore file used as the input of the Acceleo scripts contains references to another .ecore file (base.ecore) contained in another project of the workspace. File base.ecore mainly contains declarations for abstract classes and interfaces which are extended/implemented in the main .ecore file.
I created a Java service with a method isSpecification(EClass eClass) returning true if eClass extends/implements the Specification type, defined in base.ecore.
The problem is that this method always returns false. When I try to debug my code, I can see that all super types of parameter eClass are unresolved proxies, so none of these super types can be equal to my Specification type.
What is the correct way to have these proxies automatically resolved ?
Thanks in advance,
François
[Updated on: Thu, 11 June 2015 05:26] by Moderator
|
|
|
|
Re: [Acceleo] Cannot access EClass objects declared in a referenced .ecore file [message #1707150 is a reply to message #1698376] |
Wed, 02 September 2015 11:14  |
Eclipse User |
|
|
|
Hi again,
I had solved the problem temporarily by launching my MTL scripts using the Acceleo Plugin Application Runner. But I switched to Eclipse Mars where this strategy is discouraged (and does not really work).
So I reverted to the Java Application Runner, and my initial problem remains, which is: the classes of the base.ecore model referenced in the specific.ecore model used as input in my Acceleo run configuration appear as proxies, so statements like these:
rootEClass.isSuperTypeOf(aClass)
are never true, even if aClass extends rootEClass.
Here is an extract of my specific.ecore file, which is the input file of the Acceleo script. It defines an abstract class named RootClass extending class Root of the base.ecore model.
<eClassifiers xsi:type="ecore:EClass" name="RootClass" eSuperTypes="../../thales.thav.dsi.em.common.model/model/base.ecore#//Specification ../../thales.thav.dsi.em.common.model/model/base.ecore#//Root #//profiles/ProfileA #//profiles/ProfileB">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" eType="#//String">
</eStructuralFeatures>
<eStructuralFeatures xsi:type="ecore:EReference" name="classgena" lowerBound="1"
upperBound="-1" eType="#//gen/ClassGenA" containment="true"/>
</eClassifiers>
When I evaluate statement rootEClass.isSuperTypeOf(aClass) in one java service of the Acceleo script with rootEClass set to Root EClass (using BasePackage.eINSTANCE.getRoot()), and aClass set to RootClass EClass, it returns false.
In debug mode, I can see that rootEClass evaluates to:
org.eclipse.emf.ecore.impl.EClassImpl@e6619b (name: Root) (instanceClassName: null) (abstract: true, interface: true)
and aClass.getESuperTypes() evaluates to:
[org.eclipse.emf.ecore.impl.EClassImpl@c4176a (eProxyURI: file:/D:/Projets/EM-GENERATOR/src/code/specifem/thales.thav.dsi.em.common.model/model/base.ecore#//Specification), org.eclipse.emf.ecore.impl.EClassImpl@1dd4c3d (eProxyURI: file:/D:/Projets/EM-GENERATOR/src/code/specifem/thales.thav.dsi.em.common.model/model/base.ecore#//Root), org.eclipse.emf.ecore.impl.EClassImpl@1b83ac6 (name: ProfileA) (instanceClassName: null) (abstract: true, interface: false), org.eclipse.emf.ecore.impl.EClassImpl@1ab8b7 (name: ProfileB) (instanceClassName: null) (abstract: true, interface: false)]
which explains that my type Root cannot be found in the list of RootClass's super types.
I tried the following workarounds:
- replace ../.. in specific.ecore file with plugin:/platform or plugin:/resource URIs
- calling EcoreUtil.resolveAll(BasePackage.eINSTANCE) at various places of the code (in my Java Service or in method registerPackages of the Java file generated by Acceleo to run the script)
- calling resourceSet.getPackageRegistry().put(BasePackage.eINSTANCE.getNsURI(), BasePackage.eINSTANCE) in the same places
but I still have the same behaviour.
Does someone have a clue ?
Thank you,
François
|
|
|
Powered by
FUDForum. Page generated in 0.04715 seconds