Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » [XPAND] Ecore Metamodel containing EEnum
[XPAND] Ecore Metamodel containing EEnum [message #501549] Wed, 02 December 2009 18:18 Go to next message
Alexander Fried is currently offline Alexander FriedFriend
Messages: 4
Registered: December 2009
Junior Member
I am trying to enhance the existing EMF code generator by generating some supplementary classes for existing .ecore models.
As it is a rather simple class to generate, I load the .ecore file with the Reader and pass it directly to an XPand template.

Everything works fine, except when the .ecore model contains enums, or, to be more specific, EEnumLiterals. In this case, I get a very weird error message:

EvaluationException : No Definition 'Dump for model::PrimitiveTypes' found!
where model::PrimitiveTypes is an enum defined by the EEnumLiteral, i.e. XPand seems to mix up the real type of the object (ecore::EEnumLiteral) with its content.

Here is a small test XPand to demonstrate the problem and which produces the above error message:
«IMPORT ecore»

«DEFINE Dump FOR EPackage»
	«FILE "EcoreDump.txt"»
Package: «name»
		«EXPAND Dump FOREACH eClassifiers»

«DEFINE Dump FOR EClassifier»
	Classifier: «name»

	Enum: «name»
	«EXPAND Dump FOREACH this.eLiterals»

«DEFINE Dump FOR EEnumLiteral»

Any ideas on how to overcome this? I guess it is a bug in the EmfMetamodel implementation.

Best regards,

[Updated on: Wed, 02 December 2009 18:39]

Report message to a moderator

Re: [XPAND] Ecore Metamodel containing EEnum [message #501626 is a reply to message #501549] Thu, 03 December 2009 08:03 Go to previous messageGo to next message
Karsten Thoms is currently offline Karsten ThomsFriend
Messages: 762
Registered: July 2009
Location: Dortmund, Germany
Senior Member

Hi Alex,

this is intended behavior from the EMF typesystem. The metaType of an enum literal is its declaring enum type. Suppose you want to access an attribute which has an enum as type. You have to pass an element of the enum type as value, but actually you are passing a literal value. This makes Xpand in most cases very easy to handle enum typed values unless you are actually interested in the literal itself. In this case you'd have to work around a bit, e.g. by accessing the literal by its string value or using the JavaBeansMetaModel also.

Kind regards,

Need professional support for Xtext, EMF, Eclipse IDE?
Go to:
Twitter : @kthoms
Blog :
Re: [XPAND] Ecore Metamodel containing EEnum [message #501803 is a reply to message #501626] Thu, 03 December 2009 20:16 Go to previous message
Alexander Fried is currently offline Alexander FriedFriend
Messages: 4
Registered: December 2009
Junior Member
Hi Karsten,

thanks for your answer.
Unfortunately, I don't understand why this should be the intended behavior of the EMF typesystem.

Please be aware, that in my scenario Ecore is both the Meta-Metamodel (M3) and the Metamodel (M2) and the contents of the . ecore file is used as model data (M1) in the same you would usually use an .xmi file for.

In a typical (i.e not my presented) EMF model, Ecore is the Meta-Metamodel (M3) and one defines an own Metamodel in an .ecore file (M2). For such an EMF model you then have some data, e.g. in a .XMI file (M1) that you process and transform to text via XPand.
The types used in the XPand template come from M2 and are based on M3. Typically, the EEnumLiteral is an Ecore (M3) Meta-type and the real literal (M2) is the one you want to use in XPand. Everything in M1 is the processed data and definitely not a type used in XPand.

In my example, as said, Ecore is both M3 and M2, as Ecore is defined in itself. In other words, Ecore is also an EMF model.
The EEnumLiteral I was talking about is the one from M2 and its M3 Ecore Meta-type is EClass. The error/bug is now, that an M2 type with M3 EClass, that just "happens" to be called EEnumLiteral as well, is wrongly interpreted as the M1 type and the tempalte expects to find a DEFINE for the M1 type, which can't be correct. By the way, this only happens during runtime; the static typechecking is correct.

Summarizing, I can't agree to your statement that this makes sense in most cases. Instead, I'd say that the current behavior is correct if the EEnumLiteral is Meta-Metamodel (M3) and it is wrong if the EEnumLiteral is Metamodel (M2), because in this case its M3 type is EClass.

Previous Topic:[XPAND] problem applied stereotypes w EMF 2.6 and UML 3.1
Next Topic:UML2 MetaModel not applied
Goto Forum:

Current Time: Sun Aug 14 07:54:40 GMT 2022

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

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

Back to the top