Martin Taal's Blog

About EMF, Teneo, CDO, Texo, Hibernate, Open-Source ERP and other topics

Texo: Code Generation Patterns

leave a comment »

Texo provides code/JPA entity generation from ecore/xsd models specific for web server/service environments. A main characteristic of Texo is that it separates the Texo/EMF specific generated code from the core entities. This means that generated code can be used directly in other frameworks like ORM’s and GWT without additional runtime layers.

In previous posts on Texo I talked about generating JPA annotated entities, Test-Data generation and generating a DAO layer.

It is very easy to generate JPA annotated entities from an ecore/xsd model using Texo. After installing Texo, right-click any ecore/model and in the Texo submenu choose one of the generate code options.

A next question is how to extend/customize the code generation to fit to specific requirements. In this post I will talk about specific code generation patterns supported by Texo. In a subsequent post I will discuss adding/overriding Texo with your own code generation templates.

Texo supports several different code generation patterns:

  • optional safe bi-directional collection access: resulting in a more extensive (safer) api, but also a bit more complex to understand for many developers
  • list/set: use List or Set for collection instances
  • mix generated and non-generated classes: non-generated classes can be used for eclasses in the model
  • model/framework classes can be generated into a separate package: for runtime model support Texo can generate model-classes, these classes can be generated in separate classes.

All these options are described in more detail on this wiki page.

In addition to the code generation Texo provides a separate runtime layer for XML/XMI serialization, REST webservices etc.

Hope you like it! If you have any questions or remarks please visit the EMFT newsgroup or forum.

gr. Martin

Written by martintaal

January 5, 2012 at 3:50 pm

Posted in Texo

EMF Teneo: External References and persisting EObjects as primitive types

leave a comment »

Recently I have spend some time adding some nice new features to Teneo:

  • I made it easier to persist references to EObjects as varchars (URI), i.e. as external references
  • it is now possible to persist EObjects as hibernate user types/simple types

Teneo for a while already had the possibility to store external references as a string in the database. The URI to the object is persisted in this case. This makes it possible to persist part of your model in an XML file and part in the database. When reading objects from the database the references to the objects in XML are automatically handled/resolved.

I now made it a bit easier to work with these External references. You can now annotate an EClass with the @External annotation (as an EAnnotation). This gives you:

  • each EReference to this EClass is assumed to be external, the URI of the referenced object is stored in a VARCHAR column
  • no table is created for the externalized EClass

Ofcourse you can still also annotated individual EReferences with @External, the EClass and EReference annotations can be used next to eachother.

Another nice addition is the ability to store an EObject as a Hibernate user type. Before it was only possible to store values of EAttributes using a Hibernate user type. The latest Teneo build now makes it possible to annotate an EReference or an EClass with the @Type annotation. If the EClass is annotated then all EReferences to this EClass will be persisted as a hibernate user type and the EClass will not have its own table.

The @Type annotation has a type attribute which should contain the full classname of the hibernate user type implementation. For an ecore example with several examples of the user type annotation, check out this ecore model (See the Name EDataType and the Certificate EClass for specific annotations).

I hope this is useful, thanks for reading and if you are interested feel free to give feedback or ask questions on the EMF newsgroup or forum.

gr. Martin!

Written by martintaal

December 12, 2011 at 2:14 pm

Posted in Teneo

EMFT Texo: different from EMF code generation?

with 14 comments

Texo is an EMF variant which provides real pojo/JPA entity generation from ecore/xsd models.

The main difference with EMF is that the generated code does not contain any framework specific constructs. The code can be serialized, persisted etc. in standard frameworks (EclipseLink, Hibernate, GWT) without additional layers. This in contrast to EMF which for example requires a solution like Teneo at runtime to take care of persistence in Hibernate.

Still, eventhough Texo follows a different solution path than EMF, much of the same functionality is supported:

Different from EMF, Texo supports this functionality by externalizing the framework specific constructs in separate generated (optional) classes. The generated entities are not ‘polluted’ with framework constructs.

In addition to the above Texo also adds new features not provided by EMF:

Texo is targeted at the server side of web server/service environments. The current development focuses on extending the Texo runtime with generated REST XML/XMI webservices.

Thanks for reading and if you are interested feel free to give feedback or ask questions on the EMFT newsgroup or forum.

gr. Martin

Written by martintaal

December 6, 2011 at 10:40 am

Posted in Texo

EMFT Texo: model-driven test data generation

leave a comment »

When doing test driven development often/most of the time specific test data is created to test a specific situation. This makes sense as with specific test data you can test very specific functions of your code. However, creating test data is a tedious job and there is never enough time to do it all.

For Texo I wanted something different: model-driven testing, which starts with generating test data on the basis of an ecore/xsd model. With model-driven testing I only need to add a model to the test framework and the rest is taken care of: code and orm/jpa generation, test data generation, persisting, converting, comparing of results etc.

To support the Texo test framework Texo includes a test data generator: which generates EMF EObjects (with data and references) on the basis of an ecore model. The EMF EObjects can be used in other EMF tools such as EMF compare for comparing results. In Texo the EMF objects are converted to real java pojos and persisted in the database or serialized as xml/xmi.

Now, let’s see some code, how can you actually generate test data:

<pre>final ModelDataGenerator modelDataGenerator = new ModelDataGenerator();
System.err.println("Generated " + modelDataGenerator.getTotalObjectCount() + " objects ");
List<EObject> result = modelDataGenerator.getResult();</pre>

You define the eclasses you want to have in the top of the containment hierarchy (startEClasses) and a set of parameters which define the depth and breadth of the generation. The result is a list of EObjects which form the root of the containment hierarchy.

Texo test data generation tries to be smart when generating test data:

  • required efeatures are always set
  • objects which are created are re-used in references from other objects
  • for filling primitive values specific (overridable) value generators are used

This wraps it up, Texo provides test data generation and uses it for a model-driven test environment. Model-driven testing is a great addition to traditional specific testing. Model-driven testing has an attractive ‘mass’ side to it, it makes it very easy to add new models to the test environment thereby increasing the test coverage.

For more information on Texo and Texo test data generation visit this wiki page. If you have any questions or remarks please visit the EMFT newsgroup or forum.

gr. Martin

Written by martintaal

November 22, 2011 at 7:47 am

Posted in Texo

EMFT Texo: generating a DAO layer from ecore/xsd models

leave a comment »

The Dao pattern has been with us a for a while now. However, since the arrival of JPA/ORM tools there has been a lot of discussion if the DAO concept still makes sense. For me it always depends on the case, I have used the DAO pattern in some specific cases and have not needed it in other cases.

In any case, Texo offers DAO generation with some special functions which make sense to have when developing real-life applications (something I do for a living):

  • cross-referencing functionality
  • remove with cascade delete for single associations
  • findBy property
  • findBy using EStructuralFeatures (the ecore runtime model)
  • get and getAll

Okay, let’s see how to generate the DAO classes and how to use them at runtime. First ofcourse install Texo from the update site. Then after restarting, right click on a model file (ecore or xsd) and select the ‘Generate the Model + Dao code’ option. As a default the dao classes are generated in a sub package of the model code.

 * The Dao implementation for the model object '<em><strong>Forum</strong></em>'.
 * @generated
public class ForumDao extends BaseDao {

   * @generated
  public Class getEntityClass() {
    return Forum.class;

   * @generated
  public EClass getEClass() {
    return ForumModelPackage.INSTANCE.getForumEClass();

Now to get to the DAO at runtime you can use the Texo DaoRegistry class, the DAO classes are registered when the model get’s initialized in memory:

final BaseDao bookDao = DaoRegistry.getInstance().getDaoForEntity(Book.class);

Or you can use the Dao class directly:

final BookDao bookDao = DaoRegistry.getInstance().getDao(BookDao.class);

and you can for example do cross-reference checks using the DAO:

// is the book referenced, only check non-containment references

bookDao.isReferenced(book, false));

// get maximum 10 referers and include containment references

List referers = bookDao.getReferingObjects(book, 10, true);

The DAO instance gets access to an EntityManager using the Texo EntityManagerProvider, it is a light-weight concept which makes it easy to pass your EntityManager instance to the Texo runtime code.

My plan is to extend the DAO generation to automatically generate typed findBy* methods based on annotations in the model.

For more information on the DAO support by Texo visit this wiki page. And as before feel free to give feedback or ask questions on the EMFT newsgroup or forum.

gr. Martin

Written by martintaal

November 10, 2011 at 3:52 pm

Posted in Texo

Moving Texo and Teneo over to git

with one comment

More and more projects at seem to move over to git. I am using git and mercurial in several customer projects and the experience is great. I use the command line mainly and the speed, ease of branching and merging are a big plus.

So time to move Texo and Teneo over to git. Here is a summary of my experience. I will talk mainly about the changes I had to do to the buckminster build I use for Teneo and Texo. But first, credits should go to the CDO project for providing me good examples of the changes I needed to make and to the Eclipse webmasters to give very responsive help in creating the git repositories.

First to the build configuration, I had to make the following changes:

  • Set source code management to git and the url to the git repository, which for Texo is: git://
  • Then I specified in the ‘Local subdirectory for repo (optional)’ the directory within the workspace to which hudson should clone the repository. This setting can be found within the advanced section of a repository.

As a next step I had to set the correct path to the build ant script (see the ‘Build File’ field in the advanced tab of the Invoke Ant Build section), the path within the git clone local directory, in this case this was:

  • git/infra/org.eclipse.emf.texo.releng.buckminster/build.xml

So now hudson would listen to the correct location for changes and will clone the repository and run the correct build script.

Now to the build script and buckminster setup itself.

In the build xml I set a property which contains the correct path to a directory where hudson clones the git repository:

<property name="gitPath" location="${hudsonWorkSpacePath}/git" />

With Texo I let hudson do the git repository cloning. You can also tell buckminster to do it though, afaik this can be done by passing parameter named: git.clone as a jvmarg when launching buckminster.

Then I needed to change the rmap files, from using cvs to using git. Here is a snippet of one of the rmap file which reads the git repository cloned by hudson:

<provider componentTypes="osgi.bundle" readerType="git" source="true">
	<uri format="{0},tests/{1}">
		<bc:propertyRef key="gitPath"/>
		<bc:propertyRef key="buckminster.component"/>

It uses the gitPath property defined earlier to get to the correct repository location.

And this was it! So overall, the changes where quite small and Texo and Teneo build correctly from the git repositories.

For your reference here are some links to the builds projects and build pages:

For any questions/remarks please visit the EMFT Texo newsgroup or forum.

gr. Martin

Written by martintaal

November 1, 2011 at 8:42 pm

Posted in Teneo, Texo

Texo: generate JPA annotated pojos from ecore/xsd

with 4 comments

On request of a user who is using Texo with Vaadin, I spent some time on adding JPA annotation generation to Texo. It was already possible to generate an orm.xml (from an ecore model) using Texo but somehow Vaadin needed annotated classes to work with their JPAContainer.

There are several solutions out there for generating JPA annotated code (Dali and Hibernate Tools for example). So what are the advantages of using Texo over other solutions? Well here are a few:

  • generated code can be changed manually, regeneration will not remove manual code, Texo supports the same pattern as EMF
  • JPA/code generation can be controlled in detail
  • possible to generate JPA annotated code from a XSD
  • access to EMF-like functionality like XML/XMI serialization and runtime model-driven development
  • easy to adapt code generation templates or generate additional code

Now let’s see how JPA annotated code can be generated from an ecore/xsd, it is actually quite easy….

  1. First install Texo from the update site here.
  2. Then right click on an ecore/xsd file and then in the Texo submenu click ‘Generate JPA Annotated Model Code’

Generate JPA Annotated Code

As a default the generated source code will be present in the src-gen source folder:

Texo Generated JPA Annotated Code

That’s it! You can now persist your generated entities, make manual changes etc. If you need more control over the JPA generation you can annotate the model.

I hope this is enough reason to try out Texo. The JPA generation is quite new (beta) so feel free to give feedback or ask questions on the EMFT newsgroup/forum.

gr. Martin

Written by martintaal

October 26, 2011 at 8:46 am

Posted in Texo