Teneo 2.1.0 adds support for Hibernate 4.3.*

Hi,

Teneo 2.0.0 supports Hibernate 4.1.* which was released in early 2012. Since then several Hibernate versions have followed and I have planned to upgrade Teneo to the latest 4.3.* hibernate version for some time now. I promised winter 2014 before and I now spend some time on it (January 2015 is also winter of 2014 I guess :-).

So I am happy to tell you that the 2.1.0 version of Teneo is now available with support for Hibernate 4.3.*.

You can download Teneo 2.1.0 from this update site:

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

For testing and for your convenience there is also an update site for the dependencies:

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

As you can see Teneo is being tested with Hibernate 4.3.7.

Teneo supports the JPA 2.0 spec, so not yet JPA 2.1. My plan for 2015 is to spend most of my time on Texo, Teneo is more in maintenance mode now. Teneo JPA 2.1 support can however be developed as a sponsored task. So if you are interested in sponsoring this development then contact me directly at mtaal_at_elver.org.

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

EMF Teneo: Auditing it All!

Hi,

One feature missing from Teneo (until now!) was auditing, storing object state over time and allowing you to retrieve the historical state of objects. The past weeks I worked on this nice feature and currently all/most 500 Teneo testcases are run in audit mode.

The auditing functionality provides some nice functionality:

• auditing can be enabled/disabled for the complete model or for specific types
• possible to navigate/iterate over the history of an object
• possible to query for version history using HQL

Teneo auditing generates an audit model from the domain model and creates separate tables to store the audit information. All/most Ecore model constructs are supported.

There are several options available to control the auditing behavior. In addition you can annotate the domain model with JPA annotations to control the auditing database schema. This is all described in some more detail here.

Teneo provides different ways to get to the audited data, you can retrieve the audit history for a single object, use HQL querying or iterate over the history.

I am now working on integrating Teneo auditing with the CDO Hibernate Store. Allowing the user to retrieve revisons through the CDO revision api. More on that in my next post!

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

EMF Texo and Teneo available for Maven

Hi,

Traditionally Teneo and Texo are distributed through Eclipse update sites. The past year several people have asked me to make the Texo and Teneo runtime jar files also available through a Maven repository.

Recently this topic also came up for some sponsored Teneo development I am currently doing. With these requests from multiple sides it was time to make this happen!

So from today: Teneo/Texo (and their EMF dependencies) are uploaded to the Sonatype repositories (thank you Sonatype for providing this repo-service!) and from there synced to Maven central. They are all published in the org.eclipse.emf group.

The nightly builds are available on the Sonatype snapshot repository. The builds are released regularly to Maven central. You can find the jar files there:

• Teneo on Maven central
• Texo on Maven central

See these Texo and Teneo wiki pages for some more information.

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

gr. Martin

ps: when using maven with Texo, make sure to check out this troubleshooting tip.

EMF Teneo 2.0: JPA 2.0 and Hibernate 4.*!

The time has come to up the version number of Teneo from 1.2.0 to 2.0.0. The ‘technical’ reason is support for Hibernate 4.* which has a different internal api than previous versions. At the same time it is nice to announce another new feature: JPA 2.0 annotation support (see the JPA 2.0 spec). Teneo already supported the JPA 1.0 specification and the JPA EntityManager api.

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 the latest build of 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

EMF Teneo: External References and persisting EObjects as primitive types

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!

Moving Texo and Teneo over to git

More and more projects at eclipse.org 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://git.eclipse.org/gitroot/texo/org.eclipse.emf.texo.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"/>
	</uri>
</provider>

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:

• Texo: build project – build page
• Teneo: build project – build page

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

gr. Martin

Teneo: documentation moved to http://wiki.eclipse.org/Teneo and convenience update sites

This post is to ‘broadcast’ some changes in the Teneo docs location and some convenient update sites for Teneo.

The Teneo documentation has been moved completely to the eclipse wiki: http://wiki.eclipse.org/Teneo
The Hibernate specific part can be found here: http://wiki.eclipse.org/Teneo/Hibernate
The EclipseLink specific part can be found here: http://wiki.eclipse.org/Teneo/EclipseLink

The latest successful build can be retrieved from this update site:
https://build.eclipse.org/hudson/job/emf-teneo-nightly/lastSuccessfulBuild/artifact/build/result/p2site/

There is a new update site which provides the Teneo dependencies: http://www.elver.org/eclipse/update/

The tutorials have been revisited and a new examples project for Hibernate has been created to facilitate starting with Teneo:
http://wiki.eclipse.org/Teneo/Hibernate/Download_and_Install#Download_Example_Project_for_Tutorials

Building (Teneo) with Buckminster and Hudson

Recently I had to make a decision on how to setup a new continuous build environment for Teneo. After some studying I came to the conclusion that there where two main options: Athena and Buckminster. In both cases I wanted to make use of Hudson to trigger the builds and collect build results.

For Teneo I chose Buckminster because:

• I liked the way it auto-retrieves dependencies from cvs, update sites (local and remote) and many other source formats.
• Dependencies are mostly derived automatically from the MANIFEST.MF and feature.xml files in the plugin/feature projects.
• Buckminster creates workspaces with target platforms, the main other steps (building, testing) are done from these. This is a quite understandable process as it is very similar to a setup in the IDE itself.
• Buckminster has good documentation and an active forum/newsgroup with very responsive committers/developers.

The Teneo build is done by an ant script which calls Buckminster to execute specific steps. The build consists of two parts: build/create update site and build test plugins/run test cases.  For a detailed description of the Teneo build setup (Buckminster and Hudson) see this wiki page.

With the new build setup it is very easy to do a local Teneo build:

cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/modeling co -d \

org.eclipse.emf.teneo.releng.buckminster \


org.eclipse.emf/org.eclipse.emf.teneo/releng/org.eclipse.emf.teneo.releng.buckminster


cd org.eclipse.emf.teneo.releng.buckminster


ant


This executes the same steps as with a hudson-hosted build: download buckminster, check out all the projects from cvs, do a build of the core Teneo plugins, download the test projects from cvs, build them and run the tests. The output of the build can be found in the build folder which is created next to the org.eclipse.emf.teneo.releng.buckminster folder. The workspaces (build/workspace and test/workspace) can be opened in Eclipse.

The build is setup as a job in Hudson hosted at eclipse.org, Hudson takes care of the following:

• watches cvs for changes
• triggers a build when a cvs change is detected, triggering a build means for Teneo starting an ant script.
• collects the build result (failure/success) and test results, Hudson reads defined output folders/locations and parses test result xml files.

To see the build running live on Hudson hosted at eclipse.org see this page (note link can require login).

I have written a fairly detailed description on how the Teneo build has been setup (using Buckminster and Hudson). I think/hope that it can be useful for other eclipse.org projects to look at when setting up their build using Buckminster/Hudson.

PS: for those interested in build systems, it is interesting to follow the b3 developments. B3 is an incubating EMFT project which aims to simplify software build and assembly.