Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [Xcore+Standalone]? Type of EAttributes always EJavaObject
[Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1783464] Tue, 13 March 2018 11:39 Go to next message
Horacio Hoyos is currently offline Horacio HoyosFriend
Messages: 199
Registered: October 2009
Location: UK
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
Epsilon Committer
Research Assistant
University Of York
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1783465 is a reply to message #1783464] Tue, 13 March 2018 12:31 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
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)...
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785407 is a reply to message #1783465] Fri, 13 April 2018 13:52 Go to previous messageGo to next message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 200
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.
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785411 is a reply to message #1785407] Fri, 13 April 2018 14:06 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
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
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785412 is a reply to message #1785411] Fri, 13 April 2018 14:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
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?
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785416 is a reply to message #1785412] Fri, 13 April 2018 14:42 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
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
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785423 is a reply to message #1785416] Fri, 13 April 2018 15:52 Go to previous messageGo to next message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 200
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.
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785439 is a reply to message #1785423] Fri, 13 April 2018 17:48 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
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

Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785457 is a reply to message #1785439] Sat, 14 April 2018 05:33 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 29653
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.
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785462 is a reply to message #1785457] Sat, 14 April 2018 07:35 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
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
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785463 is a reply to message #1785462] Sat, 14 April 2018 08:19 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
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
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785464 is a reply to message #1785463] Sat, 14 April 2018 08:49 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6111
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
Re: [Xcore+Standalone]? Type of EAttributes always EJavaObject [message #1785467 is a reply to message #1785464] Sat, 14 April 2018 14:32 Go to previous message
Denis Nikiforov is currently offline Denis NikiforovFriend
Messages: 200
Registered: August 2013
Senior Member
Hi

Thanks a lot for your help! I added org.eclipse.emf.ecore project into workspace as a temporary workaround.
Previous Topic:Live Validation
Next Topic:Some code cannot be generated when Dynamic Templates is true
Goto Forum:
  


Current Time: Sun Nov 18 10:05:58 GMT 2018

Powered by FUDForum. Page generated in 0.02871 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top