Skip to main content

TigerTeam TRIMM - Model Driven Generator just went Open Source

TigerTeam TRIMM – Model Driven Generator is just Open Sourced in July 2013. I myself never heard of this product before and found this product by coincidence as I tried to find a JPA 2 standalone cartridge / generator available in Internet. I know that AndroMDA has some cartridges to persist Java objects but as far as I know AndroMDA only support persistence in the context of EJB 3 not as standalone JPA.

After I found this product I began to analyze the code at and found out that the idea with the Events and Listeners as Extensions is a very good idea. TRIMM also uses Maven completely and does not have any dependencies to Eclipse plugins, so you are Eclipse independent. Special to this framework is that it uses its own metamodel and does not use UML2 metamodel for the generators. TRIMM should work for MagicDraw and Enterprise Architect and it can read the files directly from those UML tools. It also uses its own Java code generator which is basically based on String outputs. A very good thing is that TRIMM offers some ready to use cartridges like Java, JPA 2 and Webservice.

It seems that TRIMM does not suffer the problems I mentioned in my older Java article at Java Lobby post and uses almost the same approach of KissMDA. Following are the differences I can see in a glance:

(1) TRIMM is using its own Java generator which is basically based on String outputs and this is not the best way to generate Java codes. Using Eclipse JDT is a lot more easier and you always get syntactically correct Java codes which can be easily unit tested like this KissMDA example.

(2) Interesting to compare the transformers for Java code generation. In TRIMM you have the class In KissMDA you use the class They both are the main entering point for the generation of Java codes. Both classes look quite similar from the way of doing the works they need to do. Using DI framework like Guice in KissMDA makes the code more readable and easier to understand.

(3) Unit tests are crucial in KissMDA. The simple Java cartridge has in the mean time about 35 test cases. This is possible because we use Mockito extensively. TRIMM Java cartridge has also some unit tests which are not many in comparison with the available implementation classes.

I really like the idea of using Events and Listeners to plug the extensions. In this context I will try to write the next KissMDA cartridge which will be a JPA 2 cartridge using Events, Event Bus and Listeners. As a foundation I will use this easy and simple Event Binder framework: GWT Event Binder. In the mean time I found some Open Source Event Bus implementations like Guava and MBassador. This is a good blog which compares those Event Bus frameworks: Java Event Bus Library Comparison. My choice is MBassador because it supports Weak References in Event Bus.

Congratulation to the team of TRIMM and I  think, it is a very good move to Open Source TRIMM. I wish all the best for the future of TRIMM!


Jeppe Cramon said…
Hi. Thanks for your coverage and feedback on TRIMM :)

The JavaGenerator uses a mixed model for java Code generation. Where possible and feasible we use a CodeModel (which is resembles the .NET CodeDOM). This means all main concepts such as Class, Interface, Enumeration, Constructor, Methods incl. arguments/return-value, Parameters, Fields all have a Java object model representation. For the Code inside methods/constructors we switch to CodeSnippets which uses String concatenation. Sometimes we skimp on using the CodeDom for certain extensions and use CodeSnippets exclusively. It's a tradeoff that we try to make very consciously.

The use of the CodeModel allows us to reuse 80% of the Code generation for Java when e.g. generating Groovy Code. The largest difference is the CodeSnippets and especially the CodeWriter and CodeVisitor that's used: GroovyCodeWriter which uses the GroovyCodeWritingCodeVisitor instead of the JavaCodeWritingVisitor.

This allows you to write Code in the following fashion:
Constructor constructor = new Constructor(CodeElement.AccessModifier.Public);
for (Property immuteableProperty : immuteableProperties) {
constructor.addParameters(new Parameter(immuteableProperty.getName(), immuteableProperty.getField().getType()));
if (!superClazzImmuteableProperties.contains(immuteableProperty)) {
constructor.addCode(new CodeSnippet("this.", immuteableProperty.getField().getName(), " = ", immuteableProperty.getName(), ";"));

Regarding the Unit testing then you're right, the amount of Unit tests are smaller compared to the amount of Code. We basically only Unit test the Core parts (parser, generator).
For most other parts, we rely heavily on vertical slice testing/integration testing. We have created several Example/test projects, which tests large parts of the Code generator and many of the extensions. We then rely on automatically generated unit/integration-tests (e.g. JpaUnittestCreator) to create integration tests for the Code we generate based on a model.
We have used TRIMM in production since 2008 and many large projects and this approach has so far proved sufficient.
Again, it has been a tradeoff of delivering quality on time and still trying to maintain the quality over time.

If you have more feedback, I would love to hear it :)

Thanks for your fast feedback and explanation!

As I said in my blog, TRIMM is the *first* MDSD framework which matches my vision of how MDSD framework should look like. Very pragmatic, lightweight and completely independent of IDE like Eclipse. So, IMHO, TRIMM is very nice. Don't worry I'll take further look on TRIMM and will give you a lot more feedbacks ;)

It's a pitty that I never heard TRIMM before it became Open Source. In January this year I wrote an article about "MDSD state of the art" at German's online developer magazine called heise Developer: and at that moment I did not know the existence of TRIMM.

Let me know, if there are things we can work together between KissMDA and TRIMM.

Henrik Wivel said…
Just for your information, we have recently released a new snapshot of TRIMM with support for Spring Data Mongo.

You can read more here:


Popular posts from this blog

Creating Spring Bean dynamically in the Runtime

In my training someone asked me whether it is possible to create an object (a Spring Bean) dynamically so you can choose which implementation you want to have in the runtime. So at the compile time you don't know what object actually should be created yet. The application should decide what object to be created based on a property file.

1. We create an annotation so we can mark the method which should be able to create the object dynamically:

package your.package;
public @interface InjectDynamicObject {
2. Use the new created annotation in your method which should be able to create the object dynamically:
... @Named("customerBo") public class CustomerBoImpl implements CustomerBo { ...     @Override @InjectDynamicObject public Customer getDynamicCustomer() {         return this.dynamicCustomer; } ...
3. Write an aspect with Pointcut and Advise which change the object returned by the method in the step 2:
... @Named @Aspect public class Dyn…

Enterprise Applications Customization with Microservice

Introduction Today in highly paced enterprise environment you, as the leader of enterprise IT division, need to be fast. Simplicity is the key for the speed. What are the key factors to simplify your IT? Three different areas are very important to take care of: Technology, Organisation and Environment(TOE Framework: Here are some detail points for technology and organisation:

1. Technology: in most enterprises there are already one or more ERP and CRM solutions the so called Enterprise Applications. We need to manage them carefully as they support the business processes. In context of the core compentencies most enterprises customize the enterprise applications to fit their needs. We need to manage the customizations in detail as they represent the core competencies and at the same time the differentiation of our enterprise to other competitors. 2. Organisation: working in a small team with different roles and functions is already proved as the best …

Smart Home Sweet Home with Gigaset Elements?

Last week I had a chance to try the Smart Home solution from Gigaset Elements. I read some articles about this product which said how easy to install this product for dummy users. Those articles woke my interest and I began to google products for Smart Home solutions.

In this article (German language) you will find a nice overview about some products for Smart Home, which can be bought in Germany. The Nest product from Google is still not available in Germany. Although it seems that RWE will offer Nest products in Germany in couple of months.

The installation of Gigaset Elements was really easy. The problem I encountered was to add the sirensensor. I had to push hard the button on the siren sensor at the same time with the button on the base, so that they can communicate with each other. After about one hour I managed to install everything properly.

Points to mention
Generally the idea is very nice. Gigaset Elements try to push KISS (Keep it Simple Stupid) principle. Howev…