Eclipse Community Forums: EMF » [Xcore+Standalone]? Type of EAttributes always EJavaObject

Help

Home

Home » Modeling » EMF » [Xcore+Standalone]? Type of EAttributes always EJavaObject

Show: Today's Messages :: Show Polls :: Message Navigator

[Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1783464]

Tue, 13 March 2018 11:39

Horacio Hoyos

Messages: 242
Registered: October 2009
Location: Mexico

Senior Member

I have a similar problem as discussed in this post , but I am trying to do it from standalone java.

This is my standalone Xcore setup:

new org.eclipse.emf.mwe.utils.StandaloneSetup().setPlatformUri("../");
Injector injector = new XcoreStandaloneSetup().createInjectorAndDoEMFRegistration();
XtextResourceSet resourceSet = injector.getInstance(XtextResourceSet.class);
resourceSet.addLoadOption(XtextResource.OPTION_RESOLVE_ALL, Boolean.TRUE);

And then I load an xcore file like so:

ResourceSet resourceSet = new ResourceSetImpl();
resourceSet.getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap(true));
Resource metamodel = resourceSet.getResource(locationURI, true);
metamodel.load(Collections.EMPTY_MAP);
EcoreUtil.resolveAll(metamodel);

The location uri is a path to a file in the system, i.e. "file:/some/path/myxcore.xcore"

Note that the xcore loads correctly and I can access the EPackage. Is just that it seems the proxies where not resolved.
As with the referenced post the issues is that all attributes have a EJavaObject type, which causes any model that conforms to the metamodel not to load correctly.

To answer some of the questions of the other post:
Quote:

After you've loaded the resource is the Ecore.genmodel in the resource set?

After resourceSet.getResource only the XPackageImpl exists in the resource. Same after load. The genModel and EPackage only appear after the resolveAll.

I am inclined to think that the ECore Package is not found when resolving proxies, which means I am missing something in the standalone setup. But I can't figure out what.

Thanks,

Horacio Hoyos Rodriguez
Kinori Tech
Need professional support for Epsilon, EMF?
Go to: https://kinori.tech

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1783465 is a reply to message #1783464]

Tue, 13 March 2018 12:31

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

In the Xcore tests, we do quite a bit of configuration to get all this to work, e.g., in org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup. I think you maybe need a bunch of stuff like that in order for the models on the classpath to be indexed and visible stand alone, but I'm really not sure of all the details. Sorry. You might be better to ask on the TMF forum because those folks will have more experience with MWE and what you need to all initialized to get it working stand alone (if that really even works)...

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785407 is a reply to message #1783465]

Fri, 13 April 2018 13:52

Denis Nikiforov

Messages: 343
Registered: August 2013

Senior Member

Hi

I have the same problem, but when I run the following QVTo transformation from Eclipse (not in Standalone):

modeltype GENMODEL uses 'http://www.eclipse.org/emf/2002/GenModel';
modeltype XCORE uses 'http://www.eclipse.org/emf/2011/Xcore';
modeltype ECORE uses 'http://www.eclipse.org/emf/2002/Ecore';

transformation XcoreToEcore(in xcore : XCORE, out ecore : ECORE);

main() {  
    xcore.objectsOfKind(EPackage).eClassifiers[EClass].eAttributes.eAttributeType->forEach (x) {
        log(x.repr());
    };
}

Types of all attributes is:

org.eclipse.emf.ecore.impl.EDataTypeImpl@4e4e642e (name: EJavaObject) (instanceClassName: java.lang.Object) (serializable: true)

Also I tried to create a genmodel+ecore from xcore and to use this ecore model as input for my QVTo transformation. It works a little bit better, but with the following problem. There are two Xcore models in my project. One Xcore model imports the other. So I create two genmodel+ecore. Attribute's types from first model a transformed fine. But all attributes in the imported Xcore model have EJavaObject type.

So it seems that something is broken in Xcore or QVTo.

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785411 is a reply to message #1785407]

Fri, 13 April 2018 14:06

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

"So it seems that something is broken in Xcore or QVTo." or your declarations or your models. Please provide a zipped repro with a .launch config.

Though I'm inclined to think that what you see is correct. If you want to use a non-model implementation class in a purely modeling context, you probably need to mention "instanceClass".

Regards

Ed Willink

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785412 is a reply to message #1785411]

Fri, 13 April 2018 14:13

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

Is the *.xcore resource in a project with Java and Xtext natures? Are the Xcore and Xbase libs on the classpath of that project?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785416 is a reply to message #1785412]

Fri, 13 April 2018 14:42

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

The asymmetry between your two models seems faintly familiar. I suspect that one may be loaded as generated java while the other is loaded dynamically, probably due to inadequate model registrations, possibly due to a badly initialized private ResourceSet. I wouldn't expect QVTo model loading to be affected by natures, but if a library is optional that might contribute to the inconsistent declarations. Anyway repro needed if you want further help.

Regards

Ed Willink

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785423 is a reply to message #1785416]

Fri, 13 April 2018 15:52

Denis Nikiforov

Messages: 343
Registered: August 2013

Senior Member

It seems that my projects have right natures. Here is a minimal example: https://github.com/AresEkb/qvto_xcore_test

If you'll run this transformation with this input model in Eclipse. You will see the following output:

org.eclipse.emf.ecore.impl.EDataTypeImpl@73db008a (name: EJavaObject) (instanceClassName: java.lang.Object) (serializable: true)

But name attribute of TestClass should have a string data type.

Here is a genmodel+ecore imported from the xcore model. The name attribute has a right (EString) data type in this model. So I expect to see the same type in the QVTo transformation.

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785439 is a reply to message #1785423]

Fri, 13 April 2018 17:48

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi

If you change your transformation to EcoreTest for test.ecore you get

org.eclipse.emf.ecore.impl.EDataTypeImpl@3a45d9c (eProxyURI: platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore#//EString)

QVTo transformations execute as a standalone application so QVTo is failing to resolve either of

<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" unique="false" eType="ecore:EDataType ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" unique="false" eType="ecore:EDataType platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore#//EString"/>

But if you edit test.ecore to one of

<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" unique="false" eType="ecore:EDataType ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" unique="false" eType="ecore:EDataType platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" unique="false" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>

or open org.eclipse.emf.ecore as a project in your workspace, you get what you wanted

org.eclipse.emf.ecore.impl.EDataTypeImpl@33b5af2b (name: EString) (instanceClassName: java.lang.String) (serializable: true)

org.eclipse.emf.ecore as a project fixes your XcoreTest too.

It looks like:

QVTo Bug/Ecore Bug. There should be a platform:/resource to platform:/plugin fallback. Since both test.ecore and test.xcore load without problem in the Sample ECORE Model Editor, the files are EMF readable, so QVTo or the Ecore initialization QVTo uses/neglects to use are at fault.
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=533564 raised.

Xcore Bug/User Bug. test.ecore should use http://www.eclipse.org/emf/2002/Ecore or platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore rather than platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore.

Xcore Bug. The unresolved proxy in Ecore is reified as an EJavaObject for Xcore-derived Xcore.

Regards

Ed Willink

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785457 is a reply to message #1785439]

Sat, 14 April 2018 05:33

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

It sounds to me like mostly what's missing is resourceSet.getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap(true)). That's what the Ecore and GenModel editors do.

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785462 is a reply to message #1785457]

Sat, 14 April 2018 07:35

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Ed

Yes. That's pretty much what I added as the candidate fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=533564

Regards

Ed Willink

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785463 is a reply to message #1785462]

Sat, 14 April 2018 08:19

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Denis

Workaround as-is today: open org.eclipse.emf.ecore as a project in your workspace. (Be patient while everything rebuilds. Restart Eclipse if you close this project).

Fix today: Install https://hudson.eclipse.org/qvt-oml/job/qvto-branch-tests/55/artifact/releng/org.eclipse.qvto.releng.build-site/target/org.eclipse.qvto-3.8.0.N20180414-0801.zip

NB the code in the fix is from a branch that has not yet been reviewed by the primary QVTo committers. The fix may not appear in M7 or future releases.

Regards

Ed Willink

Report message to a moderator

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785464 is a reply to message #1785463]

Sat, 14 April 2018 08:49

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Horacio

Having fixed the QVTo problems I can shed some light on your original observations.

Referenced resources are only loaded when the proxy that references them is resolved. It is therefore prudent to do a resolveAll early, and certainly before you attempt to iterate the ResourceSet.resources as a stable list. After a resolveAll you must examine Resource.errors in all ResourceSet.resources in order to discover proxy resolution errors. Typically there is a 'Resource does not exist' message hiding in a secondary resource's errors.

The Xcore loading appears to have a feature whereby unresolved proxies are reified as EJavaObject ohiding the underlying proxy problem.

resourceSet.getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap(true)); and EcorePlugin.ExtensionProcessor now do a pretty thorough job of initializing a simple standalone environment to behave like OSGI, but before Ecore improved, I evolved MWE2's classpath analysis in OCL's StandaloneProjectMap. I think EMF has caught up and so StandaloneProjectMap is now only necessary if you want to defeat metamodel schizophrenia nghtmares by unifying diverse loads of metamodels with the same nsURI.

Regards

Ed Willink

Report message to a moderator