Home » Modeling » GMF (Graphical Modeling Framework) » Re: 3 classes in model extend EObject - one of them causes crash - related to enum problem ?!
| Re: 3 classes in model extend EObject - one of them causes crash - related to enum problem ?! [message #146558] |
Tue, 14 August 2007 20:20  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Keith,
Comments below.
Keith Harrison-Broninski wrote:
> I assume this is the correct forum - I have a GMF problem but it is
> caused by something in my ecore.
>
> I am using GMF on Europa. 3 classes in my EMF model extend EObject.
> This works fine when generating EMF code, but for some reason, with
> one class this causes GMFGEN to crash.
>
> Here is the class as I would like it:
>
> <eClassifiers xsi:type="ecore:EClass" name="IndependentObject"
> abstract="true"
> eSuperTypes=" platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//E Object ">
>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="description" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
>
> This causes gmfgen to crash with the following error:
>
> Problems while generating code
> Exception (null:in xpt::navigator::NavigatorLabelProvider on line
> 330 'genClass.labelFeature') while generating code
> null:in xpt::navigator::NavigatorLabelProvider on line 330
> 'genClass.labelFeature'
>
> Making the class not abstract makes no difference. The only thing
> that lets GMFGEN work is removing the inheritance from EObject:
This sounds like a GMF problem not an EMF one. Extending EObject
explicitly should be fine, though it seems unnecessary. I've added the
GMF newsgroup to the "to" list of the reply for comment.
>
> <eClassifiers xsi:type="ecore:EClass" name="IndependentObject"
> abstract="true">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> <eStructuralFeatures xsi:type="ecore:EAttribute"
> name="description" eType="ecore:EDataType
> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
>
> Then GMFGEN works fine. Other classes in my model inherit from
> EObject without causing any problems. None of the attributes id, name
> or description seem to conflict with EObject, as far as I can see.
>
> For now I have had to hack the generated code for this class to make
> the Java extend EObject, which is ugly :-( Any ideas, anyone?
All the roots extend EObject by default, so I'm not sure why it matters.
>
> The only anomaly I can see in my ecore file seems to be a totally
> unrelated problem. But you never know, so here it is. When I
> validate the EMF genmodel from the gmfgen editor, it complains about
> each of the enums with the following message:
>
> The required feature 'ecoreDataType' of 'MyEnum' must be set
Yes, this is a bogus complaint. Bugzilla
https://bugs.eclipse.org/bugs/show_bug.cgi?id=199924 is open to address
it. So best to to ignore that message for GenEnums.
>
> I can't make head or tail of this - and other references to the same
> error message on the Web have not been fully explained. However,
> running validation from inside the genmodel editor does not give
> errors (although it does not say "Validation completed successfully"
> either).
>
> This does not /appear/ to be relevant to the GMFGEN problem? The
> class is not directly related to any of the enums. However, you never
> know, and any ideas about the enum errors would also be gratefully
> received!
>
> Here is a typical enum from the ecore:
>
> <eClassifiers xsi:type="ecore:EEnum" name="Language">
> <eLiterals name="EN" value="24"/>
> </eClassifiers>
>
> and the corresponding code from the genmodel:
>
> <genEnums ecoreEnum="rim.ecore#//Language">
> <genEnumLiterals ecoreEnumLiteral="rim.ecore#//Language/EN"/>
> </genEnums>
>
> I've tried making various adjustments to this specification but
> haven't managed to remove the error message.
>
|
|
|
| Re: 3 classes in model extend EObject - one of them causes crash - related to enum problem ?! [message #146587 is a reply to message #146558] |
Wed, 15 August 2007 08:02  |
 Keith Harrison-Broninski
Messages: 33
Registered: July 2009 |
Member |
|
|
Thanks Ed. I've deleted the bogus enum problem from the quoted message
below.
GMF folks - Ed asks why this a problem. As he suggests, EMF generated
classes all extend EObjectImpl. But the interfaces don't extend EObject
by default (at least, mine don't). And this results in (for me) 27
compilation problems in my generated GMF code, all method calls that
expect EObject as a parameter:
12 in XXXDiagramUpdater: constructor XXXLinkDescriptor(EObject, EObject,
IElementType, int)
6 in XXXDiagramUpdater: constructor XXXNodeDescriptor(EObject, int)
6 in XXXDiagramUpdater: XXXVisualIDRegistry.getNodeVisualID(View, EObject)
XXXDiagramEditorUtil: List<EObject>.add(EObject) [called from
attachModelToResource]
XXXDiagramEditorUtil: ViewService.createDiagram(IAdaptable, String,
PreferencesHint) [called from createDiagram]
XXXDiagramEditorUtil: View.setElement(EObject) [called from createDiagram]
In my code, IndependentObject is the root of an inheritance hierarchy,
and I can make the compilation problems go away by making
IndependentObject extend EObject. But while this works fine for EMF
generation, it prevents GMFGEN working at all, as described below.
I've tried making the subclasses extend EObject, and that has exactly
the same result - in fact, making just one of them, any one, extend
EObject causes the identical problem.
As described below, 2 other classes in my code inherit from EObject (for
similar reasons) without the problem being manifested. I've looked
through the EObject code (and even the EObjectImpl code) and cannot see
anything that overlaps with any of my own code.
?
--
All the best
Keith
Ed Merks wrote:
> Keith,
>
> Comments below.
>
> Keith Harrison-Broninski wrote:
>
>> I assume this is the correct forum - I have a GMF problem but it is
>> caused by something in my ecore.
>>
>> I am using GMF on Europa. 3 classes in my EMF model extend EObject.
>> This works fine when generating EMF code, but for some reason, with
>> one class this causes GMFGEN to crash.
>>
>> Here is the class as I would like it:
>>
>> <eClassifiers xsi:type="ecore:EClass" name="IndependentObject"
>> abstract="true"
>> eSuperTypes=" platform:/plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//E Object ">
>>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="description" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>>
>> This causes gmfgen to crash with the following error:
>>
>> Problems while generating code
>> Exception (null:in xpt::navigator::NavigatorLabelProvider on line
>> 330 'genClass.labelFeature') while generating code
>> null:in xpt::navigator::NavigatorLabelProvider on line 330
>> 'genClass.labelFeature'
>>
>> Making the class not abstract makes no difference. The only thing
>> that lets GMFGEN work is removing the inheritance from EObject:
>
> This sounds like a GMF problem not an EMF one. Extending EObject
> explicitly should be fine, though it seems unnecessary. I've added the
> GMF newsgroup to the "to" list of the reply for comment.
>
>>
>> <eClassifiers xsi:type="ecore:EClass" name="IndependentObject"
>> abstract="true">
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="id"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute" name="name"
>> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> <eStructuralFeatures xsi:type="ecore:EAttribute"
>> name="description" eType="ecore:EDataType
>> http://www.eclipse.org/emf/2002/Ecore#//EString"/>
>> </eClassifiers>
>>
>> Then GMFGEN works fine. Other classes in my model inherit from
>> EObject without causing any problems. None of the attributes id, name
>> or description seem to conflict with EObject, as far as I can see.
>>
>> For now I have had to hack the generated code for this class to make
>> the Java extend EObject, which is ugly :-( Any ideas, anyone?
>
> All the roots extend EObject by default, so I'm not sure why it matters.
|
|
|
| Re: 3 classes in model extend EObject - one of them causes crash - related to enum problem ?! [message #146614 is a reply to message #146587] |
Wed, 15 August 2007 11:50 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Keith,
Your root interfaces should extend whatever you have set in the
GenModel's Root Extends Interface property which defaults to
org.eclipse.emf.ecore.EObject. Perhaps you cleared this field?
Keith Harrison-Broninski wrote:
> Thanks Ed. I've deleted the bogus enum problem from the quoted
> message below.
>
> GMF folks - Ed asks why this a problem. As he suggests, EMF generated
> classes all extend EObjectImpl. But the interfaces don't extend
> EObject by default (at least, mine don't). And this results in (for
> me) 27 compilation problems in my generated GMF code, all method calls
> that expect EObject as a parameter:
>
> 12 in XXXDiagramUpdater: constructor XXXLinkDescriptor(EObject,
> EObject, IElementType, int)
>
> 6 in XXXDiagramUpdater: constructor XXXNodeDescriptor(EObject, int)
>
> 6 in XXXDiagramUpdater: XXXVisualIDRegistry.getNodeVisualID(View,
> EObject)
>
> XXXDiagramEditorUtil: List<EObject>.add(EObject) [called from
> attachModelToResource]
>
> XXXDiagramEditorUtil: ViewService.createDiagram(IAdaptable, String,
> PreferencesHint) [called from createDiagram]
>
> XXXDiagramEditorUtil: View.setElement(EObject) [called from
> createDiagram]
>
> In my code, IndependentObject is the root of an inheritance hierarchy,
> and I can make the compilation problems go away by making
> IndependentObject extend EObject. But while this works fine for EMF
> generation, it prevents GMFGEN working at all, as described below.
>
> I've tried making the subclasses extend EObject, and that has exactly
> the same result - in fact, making just one of them, any one, extend
> EObject causes the identical problem.
>
> As described below, 2 other classes in my code inherit from EObject
> (for similar reasons) without the problem being manifested. I've
> looked through the EObject code (and even the EObjectImpl code) and
> cannot see anything that overlaps with any of my own code.
>
> ?
>
|
|
| | |
| Re: 3 classes in model extend EObject - one of them causes crash- related to enum problem ?! [message #146634 is a reply to message #146620] |
Wed, 15 August 2007 15:02 |
Keith Harrison-Broninski
Messages: 33
Registered: July 2009 |
Member |
|
|
I spent some time trying to create a sample project, Alex, with no
success - including just the problem class in a new ecore does not give
the error. To reproduce it I had to use most of the original model,
which is huge.
Since I cannot reproduce this in a new model, and the original model
dates back to the earliest releases of GMF, I wonder if something got
broken during GMF 2 migration. I ran all the migration routines, and
recreated the GMFGEN from scratch, but still found a few funnies that
needed sorting out by hand in the GRAPH and MAP models before the code
worked again. Perhaps something is still lurking ...
--
All the best
Keith
Alex Shatalin wrote:
> Hello Ed,
>
>>> Problems while generating code
>>> Exception (null:in xpt::navigator::NavigatorLabelProvider on line
>>> 330 'genClass.labelFeature') while generating code
>>> null:in xpt::navigator::NavigatorLabelProvider on line 330
>>> 'genClass.labelFeature'
>>> Making the class not abstract makes no difference. The only thing
>>> that lets GMFGEN work is removing the inheritance from EObject:
>
> Looks like there are some problems with core deneration templates.
> Nevertheless, the exception looks very strange - line 330 of
> xpt::navigator::NavigatorLabelProvider.xpt template contains following:
>
> «IF null != genClass && null != genClass.labelFeature-»
>
> so, there should be no null-pointers..
> Can you please submitt a request and attach sample project to it?
>
> -----------------
> Alex Shatalin
>
>
|
|
|
Goto Forum:
Current Time: Sat Dec 21 16:53:52 GMT 2024
Powered by FUDForum. Page generated in 0.03944 seconds |
] 
Search
Help
Register
Login
Home
