EMF GenModel Annotations

A cheatsheet for EMF  annotations which influence the code generation of GenModels.

The “Gen” pattern

Although is has nothing to do with annotations, it is a powerful instrument during the generation process.

A method name can be suffixed with “Gen” and by that “moved out of the way”, but still be generated.

Assume you have a method that is generated an called “init”. You can rename the method to “initGen” and keep (!!) the “@generated” marker. This will let the generation tools still generate the method “init” but as “initGen”. The method “init” is missing then as has to be provided manually. But from this method you can call “initGen” and, to some degree, influence what happens.

See below for an example.



Name Description
documentation The documentation for this model element
copyright Copyright information for this model element


Name Description
get The code of the getter method.
suppressedGetVisibility “true” or “false”. Suppres the creation of the getter for this feature.
suppressedSetVisibility “true” or “false”. Suppress the creation of the setter for this feature.
suppressedIsSetVisibility “true” or “false”. Suppress the creation of the isSet method for this feature.
suppressedUnsetVisibility “true” or “false”. Suppress the creation of the unset method for this feature.


Name Description
body The body contents used when generating the method for the operation.


Name Description
create The body of the creator method.
convert The body of the convertor method.



Name Description
constraints A whitespace delimited list of constraints.The constraint expression is then fetched from an annotation of the same model element. All validation delegates (URIs) are tried to load as annotation URI with the constraint name as value.

So for example if a model element has “constraints=test1 test2” and the package has the “validationDelegates” value set to “urn:delegate1” then the annotation urn:delegate1#test1 and urn:delegate1#test2 will be loaded.

If there is no expression present it will create a dummy method in the Validator class with must be implemented by the user. And marked with “@genenreated NOT”.


Name Description
validationDelegates  A whitespace separated list of validation delegate URIs.e.g. “urn:deletegate1 urn:delegate2”



A “Gen” pattern example

  * ...
  * @generated
public static CommonPackage initGen () {
   if ( isInited ) {
      return (CommonPackage)EPackage.Registry.INSTANCE.getEPackage ( CommonPackage.eNS_URI );

   final CommonPackageImpl theCommonPackage = (CommonPackageImpl) ( EPackage.Registry.INSTANCE.get ( eNS_URI ) instanceof CommonPackageImpl ? EPackage.Registry.INSTANCE.get ( eNS_URI ) : new CommonPackageImpl () );

   isInited = true;
   WorldPackage.eINSTANCE.eClass ();
   theCommonPackage.createPackageContents ();
   theCommonPackage.initializePackageContents ();
   theCommonPackage.freeze ();

   EPackage.Registry.INSTANCE.put ( CommonPackage.eNS_URI, theCommonPackage );
   return theCommonPackage;

public static CommonPackage init () {
   final CommonPackage result = initGen ();
   EValidator.Registry.INSTANCE.put ( result, new ExtensibleValidationDescriptor () );
   return result;

3 thoughts on “EMF GenModel Annotations

  1. Hi,

    I am trying to override generated “get” method with my custom implementation using EAnnotation with get details. For me it does not work. Can you explain in more details how to override getter method?

      1. Useful post. Good title.

        About the “get” annotation – did you flag the feature as volatile? It only applies to features that EMF doesn’t generate a field for.

        Unfortunately, ecore won’t let you declare an operation with the getter’s signature 🙁

Leave a Reply

Your email address will not be published. Required fields are marked *