Hibernate 4.1 is a major release and it is not binary compatible with 3.6.0. This means that when getting the latest CDO Hibernate store 4.1 version you also need to upgrade Hibernate to 4.1, and if you are testing using hsqldb then make sure to also upgrade that one.

To help you out, the newer hibernate and hsqldb versions are available through this update site:

http://www.elver.org/eclipse/2.0.0/update

The CDO Hibernate Store 4.1 depends on Teneo 2.0 which you can find on this update site:

http://download.eclipse.org/modeling/emf/teneo/updates/2.0.0/interim/

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

gr. Martin

The JPA 2.0 annotation development has been made possible by the sponsorship of an active Teneo user-company. It is great to see that there are companies out there who appreciate what we do at the Eclipse Modeling group and specifically ofcourse Teneo!

JPA 2.0 annotations can be defined in-the-model as well as in a separate xml file.

To summarize Teneo is now available in 2 actively maintained versions:

1.2.0:

• JPA 2.0
• Hibernate 3.6/EclipseLink 2
• EMF 2.6 and 2.7
• Eclipse Helios

2.0.0:

• JPA 2.0
• Hibernate 4.1
• EMF 2.7 – 2.8
• Eclipse 3.7 and further

Note the JPA 2.0 support is available in both versions of Teneo, the main difference between the 2 versions is the supported Hibernate version.

Active development of new features is done in the 2.0.0 version, but bugs/issues will be actively fixed in 1.2.0 for the foreseeable future.

I am currently upgrading CDO Hibernate Store to Teneo 2.0.0, that should be finished soon to!

For more information on dependencies and how to get these new versions, visit the Teneo wiki download & install page. This page also lists the update site with the latest Hibernate and hsqldb plugins.

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

gr. Martin

Next to the work I am doing on an EMF JSON resource, and solving some bugs, I was very motivated to get a nice new feature into Texo: automatic code generation on model file changes.

After each model change you have to go through the somewhat cumbersome right click on a project file and finding the Texo menu to generate your code.

This has now become a lot easier! In the Texo project properties you can now define, that code should be automatically generated when a model file changes. This includes changes to xsd’s and annotation model files.

The project properties allow you to set different things like if only certain model files should trigger a regenerate, or if JPA or DAO classes need to be generated. It is all described here.

So just check the correct flag in the project properties and your code is generated on-the-fly and more importantly: automatic.

Thanks for reading and I hope this blog post helps to give Texo a try. Visit the Texo wiki for more information. Let me know if you have any questions or remarks on the EMFT newsgroup or forum!

gr. Martin

After working on Texo JSON Rest, the next step for me has been to implement an EMF Resource which persists its data using JPA annotated entities in a standard ORM.

This makes it possible to use Texo in a RCP environment with an EMF generated front-end and a Texo generated JPA backend.

The first implementation of the TexoResource supports a 2-tier architecture: the JPA TexoResource communicates directly with the database through the JPA/ORM layer.

My next step will be to implement a Texo JSON Resource which communicates using JSON with a server running Texo. The server side of this 3 tier architecture is already done: the Texo JSON web service layer. For an example project running Texo in Tomcat/web container check out this wiki page or see this video.

For this new development I am developing EMF JSON converters, these could be useful also in other solutions, you can find the relevant plugin here in git.

I am cooperating with others to develop an example RCP using Texo. My goal is to provide more example projects. If you are interested in cooperating on this, ping me on the Texo forum.

Thanks for reading and I hope this blog post helps to give Texo a try. Visit the Texo wiki for more information. Let me know if you have any questions or remarks on the EMFT newsgroup or forum!

gr. Martin

As always, Eclipsecon was an inspiration to finally implement those features which I always wanted to do. This time it was implementing JSON REST web service support in Texo. This new feature is based on my experience implementing RIA user interfaces for business web apps.

Texo automatically provides the JSON REST web service support using the ecore/xsd domain model. So with just a few lines of code your domain model is accessible from browser/mobile web UIs.

Why would it be a good idea to try out and use the Texo JSON functionality? Well first it is quite feature complete, supporting full CRUD, querying in multiple ways, individual update/inserts, mass delete/update/insert, proxying, etc. The second good reason is that it is based on real application experience, this explains why attention has been paid to details as querying for multiple values to fill a grid, record counting and object titles. The third good reason: the combination of JSON REST with the other Texo features (JPA entity generation, runtime layer, etc.) makes it possible to have a running feature-complete JSON REST function within a few minutes, generated from an ecore/xsd model.

Texo JSON runs typically in a web container like Tomcat. The example project illustrates how to set this up. After installing/running the solution in a web container, you can for example do these type of uris/queries to retrieve information:

• http://localhost:8080/texo/jsonws/Writer/1
• http://localhost:8080/texo/jsonws/Writer
• http://localhost:8080/org.eclipse.emf.texo.web.example/jsonws?query=select e from Writer e

The first example will retrieve a single object in JSON format, the second all Writer objects and the third example shows how a free-format query can be passed. Security and SQL injection prevention are important topics here to.

Insert/update are supported through POST http methods, deletion is done through the DELETE http method.

Other features of the Texo JSON REST support:

• Paging parameters to support efficient scrolling through a large grid of data
• Setting the number of levels in the containment tree which should be returned
• The proxy concept, references are sent back with a proxy uri, to prevent reading the complete database
• Several ways of doing insert/update
• Combining multiple insert/update/delete actions in one request

As a next step I am considering implementing a few example web apps using client side UI technology as provided by sencha or even try to connect a RCP with an EMF UI to the Texo JSON layer.

Thanks for reading and I hope this blog post helps to give Texo a try. Visit the Texo wiki for more information. Let me know if you have any questions or remarks on the EMFT newsgroup or forum.

gr. Martin

Texo uses XPand as the templating language, the first question is why use Texo and not use XPand directly, well here are several good reasons:

• EMF merging: Texo supports the same merging of manual code as EMF, you can manually change the generated code, manual changes will be retained when regenerating, so if you generate your code with the @generated javadoc tag you will get EMF merging for free (incl. support of merging of annotations etc.)
• Code formatting: Texo makes sure that your code is formatted according to the development project code formatting standards
• Import resolving: an important/difficult topic to solve yourselve, just generate all your code with fully-qualified class names, Texo will do automatic import resolving for you.
• Efficient/Effective: a source file is only touched if it is actually changed by Texo, so your code will not show unneeded diffs, source files which are not needed anymore are automatically removed

All this is available out-of-the box and will work for all your generated code! Now how to extend/override code generation?

Let’s first see how to generate Texo standard code, it is very easy… After installing Texo, right-click any ecore/model and in the Texo submenu choose one of the generate code options.

Texo Entity Generation

Now the next step is to add/override Texo templates, it is a just few steps:

• add the Texo nature to the project

Add Texo nature

• create a folder structure inside your development project, the folder structure must match the template path in Texo
• place your own templates in the folder structur
  

  Texo

Now let’s see an example of a template, here is one which generates a simple subclass of a generic DAO:

«IMPORT org::eclipse::emf::texo::modelgenerator::modelannotations»
«IMPORT org::eclipse::emf::texo::annotations::annotationsmodel»
«IMPORT org::eclipse::emf::ecore»
«IMPORT org::eclipse::emf::texo::generator»

«EXTENSION org::eclipse::emf::texo::modelgenerator::templates::util»

«DEFINE root(ModelController modelController) FOR EClassModelGenAnnotation-»

«LET ((EPackageModelGenAnnotation)this.ownerEPackageAnnotation) AS ePackageAnnotation»

«FILE "org/eclipse/emf/texo/example" + toLowerCase(ePackageAnnotation.name) + "/" + this.simpleClassName + "HbDaoImpl.java" java-»
package org.eclipse.emf.texo.example.daoimpl.«toLowerCase(ePackageAnnotation.name)»;

/**
 * The Dao implementation for the {@link «this.qualifiedClassName»} entity.
 * @generated
*/
public class «this.simpleClassName-»HbDaoImpl extends org.eclipse.emf.texo.example.GenericDaoHbImpl<«this.qualifiedClassName», Long> implements org.eclipse.emf.texo.example.dao.«toLowerCase(ePackageAnnotation.name)».«this.simpleClassName-»Dao
{

/**
 * @generated
 */
 public «this.simpleClassName-»HbDaoImpl(org.eclipse.emf.texo.example.HbSessionProvider sp, org.eclipse.emf.texo.example.dao.DaoFactory df) {
 super(«this.qualifiedClassName».class, sp);
 }

}
«ENDFILE-»
«ENDLET»
«ENDDEFINE»

See that the @generated doc tag is used, this makes it possible to manually change the generated code, and re-generate without loosing your changes.

This was basically it, so it is not more than adding your own templates and tell Texo where to find them.

Thanks for reading! Visit the Texo wiki for more information. Let me know if you have any questions or remarks on the EMFT newsgroup or forum.

gr. Martin

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

• 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!

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:

• XML/XMI serialization
• supports for many XSD constructs (xsd:choice for example)
• runtime model access
• safe bi-directional associations
• supports manual changes in generated code (same pattern as EMF)

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:

• generation of JPA annotated code (with manual merging)
• flexible code generation (extendable, support for list/set, etc.)
• java annotations from model to code

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

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();
modelDataGenerator.setStartEClasses(eClasses);
modelDataGenerator.setMaxDepth(maxDepth);
modelDataGenerator.setCollectionSize(collectionSize);
modelDataGenerator.setDataSize(dataSize);
modelDataGenerator.setMaxObjects(maxObjects);
modelDataGenerator.setEPackages(ePackages);
modelDataGenerator.generateTestData();
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