Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 458621

Summary:

References to Ecore are not resolved correctly when generating ecore from xcore

Product:

[Modeling] Ecoretools

Reporter:

Rainer Menke <rainer>

Component:

General

Assignee:

Project Inbox <ecore-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

cedric.brun, mtaal

Version:

unspecified

Target Milestone:

3.0.0M6

Hardware:

OS:

Windows 7

See Also:

https://git.eclipse.org/r/41651
https://git.eclipse.org/c/ecoretools/org.eclipse.ecoretools.git/commit/?id=0bfb9212a81b7bef85de37fe838bf11399b863a2

Whiteboard:

Bug Depends on:

458841

Bug Blocks:

423904

Attachments:

Description	Flags
Sample project	none
Ecore diagrams of the models	none
Diagram with fix of 458841 and EcoreTools master	none

Description Rainer Menke

2015-01-28 04:59:20 EST

Created attachment 250293 [details]
Sample project

The bug Bug 423904 - References to Ecore are not resolved correctly when generating code, seems to be assigned to the wrong component. Just using the the generation and export functionality of ecore from xcore with org.eclipse.emf.ecore.xcore.sdk.feature.group ( 1.2.1v20141013-0331 ), it is possible to reproduce the behaviour of the unsolvable Reference to Ecore. 

I can reproduce it in the following way:

1.) Modelling an ecore:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="TestEcore" nsURI="http://www.malime.de/test" nsPrefix="test">
  <eClassifiers xsi:type="ecore:EClass" name="TestClass">
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="TestString" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
        defaultValueLiteral="&quot;Test&quot;"/>
  </eClassifiers>
</ecore:EPackage>

2.) Generate genmodel from ecore:

3.) Export genmodel to xcore:

@Ecore(nsPrefix="test", nsURI="http://www.malime.de/test")
@GenModel(modelDirectory="/relative.resolve/src", importerID="org.eclipse.emf.importer.ecore")
package TestEcore

class TestClass {
	String TestString = "\"Test\""
}

4.) Generate genmodel and ecore from xcore:

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="TestXcore" nsURI="http://www.malime.de/test" nsPrefix="test">
  <eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
    <details key="modelDirectory" value="/relative.resolve/src"/>
    <details key="importerID" value="org.eclipse.emf.importer.ecore"/>
  </eAnnotations>
  <eClassifiers xsi:type="ecore:EClass" name="TestClass">
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="TestString" unique="false"
        eType="ecore:EDataType ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EString"
        defaultValueLiteral="&quot;Test&quot;"/>
  </eClassifiers>
</ecore:EPackage>

To summarize this, in the start it was modelled

<eStructuralFeatures xsi:type="ecore:EAttribute" name="TestString" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"

in the ecore file, in the end it is generated as 

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

Comment 1 Ed Merks

2015-01-28 20:37:58 EST

Is ../../org.eclipse.emf.ecore/model/Ecore.ecore actually wrong?  With Xcore, the inferred Ecore model does consistently always use the development time version of built-in models, so what you show is what I'd generally expect.  So I wonder, how is it wrong?  I.e., does it validate as invalid when opened in the Sample Ecore Editor?

Comment 2 Rainer Menke

2015-01-29 04:36:05 EST

Created attachment 250336 [details]
Ecore diagrams of the models

Comment 3 Rainer Menke

2015-01-29 04:50:18 EST

Hi Ed,

I agree to your point, that the inferred Ecore model does consistently always use the development time version of built-in models. 

But it seems for me, that there is something wrong. First I do not know, how to generate such model without typing it manually. Second, neither the Ecore Diagram Tools nor Acceleo can work with the ecore model, because they can not determine the type of TestString. From my point of view, either the generation possiblilities of xcore should be enhanced, that absolute instead of relativ URI can be used, or several components which are based on ecore models should behave in this way.

Because you are much familiar with EMF and all dependent components than myself, perhaps you know, what would be the best way to solve the issue.

Comment 4 Rainer Menke

2015-01-29 09:24:07 EST

Hi Ed,

I played and changed a little bit. First, it is trivial, to generate a URI like you mentioned, by using the Load Resource option. But even after installing Sirius ( 2.0.3.201501210814 ) and the Ecore Diagram Editor	( 3.0.0.201412161004 ) it does not show the Etype.

Comment 5 Ed Merks

2015-01-29 16:29:53 EST

If the model opens without validation errors in the Sample Ecore Editor then it's a valid model.  It may well be that other tools don't process it properly but that's a problem in that tool.  Likely the problem is that the tool is calling the deprecated http://download.eclipse.org/modeling/emf/emf/javadoc/2.10.0/org/eclipse/emf/ecore/plugin/EcorePlugin.html#computePlatformURIMap%28%29 instead of the newer API or perhaps it isn't calling either one but should...

So it seems better if the Ecore Tools guys have a look (because I won't be able to help until early March).

Comment 6 Cedric Brun

2015-01-29 16:57:57 EST

Ed, you're probably right.
I'll have a look.

Comment 7 Cedric Brun

2015-01-30 03:36:52 EST

Rainer, can you tell me if the org.eclipse.sirius.common.xtext bundle (or the corresponding org.eclipse.sirius.runtime.ide.xtext feature) is in your environment?

Comment 8 Rainer Menke

2015-01-30 04:23:43 EST

Hi Cédric,

I have the following: 

Sirius Integration with XText	2.0.3.201501210814	org.eclipse.sirius.runtime.ide.xtext.feature.group 

and

Sirius Core Runtime	2.0.3.201501210814	org.eclipse.sirius.runtime.feature.group 

from generating Ecore Diagrams installed.

Comment 9 Cedric Brun

2015-01-30 11:43:48 EST

It looks like whatever "setup" EcoreTools was doing was un-done by Sirius. I tracked Bug 458841 

I also found a mismatch in reflective code which would make the computePlatformURIMap(false) to be called in EcoreTools (hence commit 9d059eacbcbc4b9ab47b7bcbc095ee79ff1d6a1a on master) for EcoreTools

Comment 10 Cedric Brun

2015-01-30 11:53:33 EST

Created attachment 250390 [details]
Diagram with fix of 458841 and EcoreTools master

Comment 11 Eclipse Genie

2015-02-11 12:04:45 EST

New Gerrit change created: https://git.eclipse.org/r/41651

Comment 12 Eclipse Genie

2015-02-11 12:09:20 EST

Gerrit change https://git.eclipse.org/r/41651 was merged to [master].
Commit: http://git.eclipse.org/c/ecoretools/org.eclipse.ecoretools.git/commit/?id=0bfb9212a81b7bef85de37fe838bf11399b863a2

Comment 13 Martin Taal

2015-02-16 09:54:58 EST

*** Bug 423904 has been marked as a duplicate of this bug. ***

Comment 14 Cedric Brun

2015-03-23 09:18:43 EDT

Fixed for 3.0.0M6