Texo/Code Generation Details

Introduction

The Texo code generation is controlled by annotations on the model. These annotations control the class names, names of methods and java package names. When Teneo generates code it will automatically create these annotations (in-memory) for each model element (EClass, EStructuralFeature). However, it is also possible to define these annotations in a so-called Annotations Model. This gives you the possibility to override the choices made by the Texo code generator. Texo will use these manual annotations and add its own annotations to have a complete annotated model.

This document describes how the annotations model works and how you can generate/define the annotations model.

Note: annotations model can only be used for ecore models stored in .ecore files so not for xsd's. You can easily create an ecore model from an xsd by right-clicking a xsd and then do Texo > Create Ecore Model.

What is an Annotations Model

An annotations model is very similar to the ecore model. An annotations model has references to the original ecore model and adds extra information to store directives for code generation. The screenshot below shows an example of an annotations model.

The above screenshot shows an annotations model. The model follows the same structure as the original ecore model (the rental.ecore in this example). So there is a node for the EPackage, there are nodes for each EClass/EDataType and for each EStructuralFeature.

Within each node you can see the annotation. The nodes starting with 'Model Gen', in this case the annotations are for generating model code (the entities). For example the node 'Annotated EPackage: org.eclipse.emf.texo.test.model.samples.rental' has a child node 'Model Gen Annotation rental' which contains the properties used to generate java entities.

The screenshot selects a model gen annotation for the EAttribute RentalBicycle.type. In the properties view you can see the properties which are used by the code generation. For example the name of the generated getter and setter java methods.

How to create an Annotations Model

The first step in creating an annotations model. You can create a first annotations model by right clicking an ecore file and selecting the menu option 'Texo', then three menu options are shown to you (menu titles may slightly vary):

• Create Initial Empty Annotations Model: this will create an annotations model with only nodes for the EPackages, the annotations model does not contain any annotations. These can be added individually (see below).

• Create/Update Annotations Model Structure: this will create an annotations model with nodes for all model elements of the original model. This means that there are nodes created for all EPackages, EClasses, EDataTypes and EStructuralFeatures. But no annotations are created, these can be added manually (see below).

• Create/Update Completely Annotated Model: this will create a fully annotated model with an annotation for all model elements and all model elements of the original model are present.

Manually adding annotations, Editing annotations

Annotations can be added manually by right clicking on a model node in the Annotations Model and then choose New Child. The available annotations which can be added are listed as children. In the screenshot below a Model Gen Annotation can be added. This type of annotation is used to control the generation of java entities.

After adding an annotation you can edit the annotation properties in the properties view:

How Texo uses the Annotations Model

The annotations model needs to be located in the same folder as the ecore model it applies to. The name of the file should be equal to the ecore model file name, only the file extension is different, instead of .ecore it should end on .annotationsmodel.

When code is generated for an EPackage or when an EPackage is referenced then Texo will automatically read the annotations model file. Texo will preserve all the annotations in the file and only add annotations or set features which have not been set manually.

Partially Annotating a Model

You only need to specify annotations for the parts of the code generation you want to override. So an annotations model with only a few annotations is fine. Texo will automatically add/generate annotations without overriding the manually created annotations. Even the properties/features of an annotation only need to be partially specified, Texo will automatically set the non-set properties/features of a manual annotation.

Code Generation Properties (annotations)

This section gives a detailed description of the properties/features in the annotations model used for code generation.

Note: when editing Model Gen annotations a short description of the property is shown in the status bar in the bottom of the Eclipse window.

EPackage Model Gen Features

• Add Runtime Model Behavior: Texo will generate 2 classes (the ModelFactory/ModelPackage) for integrating the java entities with a runtime Model. These 2 classes have dependencies on EMF. Set this property to false if you don't want any EMF compile time dependency, the consequence is that there is no runtime model and no XML/XMI serialization support. If set to true then the ModelFactory/ModelPackage are generated and the model is then available at runtime (with XML/XMI serialization support).
• Documentation: is added to the javadoc of the generated ModelPackage/ModelFactory classes.
• Feature Map Class Name Postfix: to support EMF FeatureMaps Texo generates extra classes, the value of this property is used as the post fix of the class name.
• Generate save many access: if set to true will generate additional methods for adding/removing elements from an EReference which has many==true. For more information see this page.
• Java File Header: is placed in the header of each generated java file, can be used for copyright statements.
• Model Classes Package Path: makes it possible to generate the ModelFactory/ModelPackage classes in a separate package from the entity classes themselves. See here for more information.
• Model Factory Class Name Post Fix: the post fix of the classname used for the Model Factory class.
• Model Package Class Name Post Fix: the post fix of the classname used for the Model Package class.
• Package Path: the java package in which the java entities are generated.
• Simple Class Name: the class name used for the Model Package (if set then the 'Model Package Class Name Post Fix' property is ignored).
• Simple Model Factory Class Name: the class name used for the Model Factory (if set then the 'Model Factory Class Name Post Fix' property is ignored).

EClass Model Gen Features

• Class Extends: the fully qualified class name of the super class
• Class Implements: a list of fully qualified names of interfaces implemented by this class.
• Generate Code: if false then no code is generated for this EClass, the qualified class name is used for references to this EClass. See here for a description of the usecase.
• Qualified Class Name: the fully qualified java class name used for this EClass.
• Serializable: if true then the java class will extend java.io.Serializable.