|
| Re: XCore to Ecore conversion problem with ECore references [message #1255548 is a reply to message #1255447] |
Mon, 24 February 2014 15:08   |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vasilis,
Comments below.
On 24/02/2014 2:26 PM, Vasilis Samoladas wrote:
> Hi
>
> when converting an XCore model to an ECore model, as outlined in the
> xcore documentation, the generated ecore file contains relative path
> references to the
> ecore data types.
>
> For example, the following xcore model
>
> package test.model
>
> class Foo {
>
> long x
> String y
>
> }
>
>
> will generate the following ecore
>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0" xmlns:xmi="hyttp://www.omg.org/XMI"
> xmlns:xsi="hyttp://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="hyttp://www.eclipse.org/emf/2002/Ecore" name="model"
> nsURI="test.model" nsPrefix="model">
> <eAnnotations source="hyttp://www.eclipse.org/emf/2002/GenModel">
> <details key="basePackage" value="test"/>
> </eAnnotations>
> <eClassifiers xsi:type="ecore:EClass" name="Foo">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="x"
> unique="false" eType="ecore:EDataType
> ../../org.eclipse.emf.ecore/model/Ecore.ecore#//ELong"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="y"
> unique="false" eType="ecore:EDataType
> ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EString"/>
> </eClassifiers>
> </ecore:EPackage>
>
>
> Taking a look at, e.g.,
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="x"
> unique="false" eType="ecore:EDataType
> ../../org.eclipse.emf.ecore/model/Ecore.ecore#//ELong"/>
>
> you can see the problem; it should have been
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="x"
> unique="false" eType="ecore:EDataType
> hyttp://www.eclipse.org/emf/2002/Ecore#//ELong"/>
Either should work okay. But note that the former refers to the
development time version of Ecore.ecore while the later really refers to
the runtime version, i.e., to EcorePackage.eINSTANCE's EDataTypes. The
generator is happy with either.
>
>
> As a result, Texo generation barfs on the generated .ecore file
I seem to recall Martin having a minor issue with Texo related to this,
which if I recall correctly is due mainly to missing this type of
initialization of the resource set:
editingDomain.getResourceSet().getURIConverter().getURIMap().putAll(EcorePlugin.computePlatformURIMap(true));
This is what makes
platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore look like
it's a project in the workspace, even when it's not actually present in
the workspace...
>
>
> Is this a known issue of am I doing something wrong?
I think it's a Texo issue and I know (via private email exchanges) that
Martin was trying to make Texo work directly with Xcore resources,
though I'm not sure the state of that. Maybe the latest version just
works...
>
> Thank you in advance,
> Vasilis
>
> [N.B. In the code saples above, hyperlinks start with hyttp protocol
> because the eclipse forum would otherwise not accept the message !!!
> It claimed that I cannot include "too many" hyperlinks...) ]
It might also limit you until you've posted at least 5 times without
being blocked as a spammer.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XCore to Ecore conversion problem with ECore references [message #1257053 is a reply to message #1255548] |
Wed, 26 February 2014 03:03 |
Vasilis Samoladas
Messages: 2
Registered: February 2014 |
Junior Member |
|
|
Thank you Ed, that was a helpful response. Martin Taal has written in the Texo wiki that the xcore integration
is ready but not yet released. Hopefully it soon wil be. In the meantime I will see if I can patch the initialization in my Texo plugin per your suggestion, as in interim solution.
However, I still think that the xcore2ecore transofrmation (independently of the Texo issue) should not use _relative_ links in the generated ecore model.
I am not sure, semantically speaking, about which Ecore version (development or runtime) should
be referenced in the generated ecore. Is there an argument for one vs the other?
Vasilis
[Updated on: Wed, 26 February 2014 03:05] Report message to a moderator |
|
|
| Re: XCore to Ecore conversion problem with ECore references [message #1257158 is a reply to message #1257053] |
Wed, 26 February 2014 05:54 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Vasilis,
Comments below.
On 26/02/2014 4:03 AM, Vasilis Samoladas wrote:
> Thank you Ed, that was a helpful response. Martin Taal has written in
> the Texo wiki that the xcore integration is ready but not yet
> released. Hopefully it soon wil be. In the meantime I will see if I
> can patch a private Texo as in interim solution.
>
> However, I still think that the xcore2ecore transofrmation
> (independently of the Texo issue)
> should not use _relative_ links in the generated ecore model.
In EMF 2.9 I added proper support for resolving references to the target
platform. Using that new support, all models visible in the target
platform are accessible via a platform:/resource URI, so
platform:/resource/org.eclipse.emf.ecore appears as a project in the
workspace (via mappings in the resource set's URI converter's URI map
and as a result
platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore is visible
and is used by Xcore resources to resolve references to Ecore's built-in
types. So the *.xcore resource in your workspace really refers to a
resource with URI
platform:/resource/org.eclipse.emf.ecore/model/Ecore.ecore. Exporting
that to *.ecore preserves those references, and when serialized those
references are relative just as is the case for all references that
resolve into the workspace. Moreover, when that *.xcore or *.ecore
resource is bundled into your runtime jar and is loaded as a
platform:/plugin URI, those relative references will also resolve to
platform:/plugin URIs allowing the resources to properly resolve at
runtime as well.
So it's fine, normal, and expected for models to refer to other models
via relative URIs. It's only Ecore that's special and generally
supports the approach of referencing the model via the nsURI, but it's
certainly not wrong to refer to another model via a logical/physical
URI, and is even necessary in the case that you extend the classes of
the other model.
>
> I am not sure, semantically speaking, about which Ecore version
> (development or runtime) should be referenced in the generated ecore.
Generated models always refer to other generated models via their nsURI
which resolves to the real generated runtime XyzPackage.eINSTANCE.
> Is there an argument for one vs the other?
See above. :-P
>
> Vasilis
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03006 seconds
] 
Search
Help
Register
Login
Home
