Less EMF!

This year's Eclipse summit was a great success, again. Before I start to chatter about the modeling technologies that I found most interesting, I'd like to point out that there also seems to be some sort of anti modeling coalition. It's clear that the public statement that "Modeling sucks!", without further reasoning, is more likely to create common hilarity than constructive engagement in the challenges and opportunities. A pity that I missed the Foundation 2.0 talk!

I noticed that others took the war against modeling and EMF in particular more seriously. There seems to be a whole industry concerned with devices that shield against EMF and the like. They are sold with the slogan "Less EMF", go figure:

http://www.lessemf.com

Of course these attempts to discredit the value of modeling are doomed to failure, as the overwhelming interest in Eclipse modeling technologies at the past summit demonstrated. The tutorial about Advanced Programming Techniques with EMF and CDO was so overly crowded that the organizers had to take all tables out of the room and make place for almost 100 attendees.


At least the same amount of interested persons stayed in that room to participate in the discussions of the following modeling symposium. All the other talks (24 total) and BOFs about modeling had been extremely well attended, too. Some of them were of particular interest for me and the CDO Model Repository project:

• The new EMF Model Query provides an SQL-like query language, cool (Xtext-based?) tooling and an extensible query orchestration and interpretation framework. The SAP team announced that an integration with the CDO server side is very interesting.
  
  
• Frederic Jouault and Hugo Bruneliere compared Eclipse modeling and Microsoft Oslo technologies and had some ideas how to bridge the two worlds and transform artifacts between both. They mentioned that Oslo misses a model repository.
  
  
• Cedric Brun demonstrated the Acceleo generator tooling and gave insights to the process of bringing this project into Eclipse.org. The tooling looked so comfortable that I thought I should give generative approaches a new chance in the CDO code itself.
  
  
• Kenn Hussey and Raphael Faudougave a BOF and a talk on Papyrus, the new integrated modeling environment at Eclipse.org. These ones were really interesting because some large companies announced that they want to participate in a general initiative with the goal of providing a commercial quality modeling tool with various diagramming support, queries, refectorings and a lot more. CDO was seen in the center of this new architecture to provide client-side scalability, model storage and collaboration.
  
  
• Markus Herrmannsdoerfer gave a talk that I awaited for a long time already. It was about the COPE framework that seems to do a great job to assist with model evolution (they call it adaptation) and the subsequent instance data migration. Very interesting stuff! Many CDO users have asked for more support in this area and it's clear that we need to provide solutions in a world of changing businesses.
  
  
• Hajo Eichler demonstrated his ideas on executable models. And he did that very well. Last not least because he copied major parts of my own slides. Sure, he asked for my permission, but because he also changed the copyright to his own's Ed announced that we might send the police after him. Two minutes later we could hear their alarms from outside and he got really worried. Poor Hajo!
  
  
• Goulwen Le Fur gave an introduction to the new Extended Editing Framework project which is about generating "sexy" properties sheets and possibly object data entry forms. I really hope that they add support for reflective models soon, so that we can use this cool technology in our CDO Explorer UI.

Today it's exactly one year ago that I startet blogging and since that time I was allowed to realize how much positive impact a little marketing can have on a technology like CDO. Some of my friends startet a private competition in finding modeling talks at the summit with no mention of CDO. Not an easy task ;-)

I realize that these days more and more modelers are interested in a model repository, either for using it as a runtime platform for their own products or for storing their design time models. I'm glad that we, the CDO team, have forseen this interest and for the future I hope that we can have even more collaboration and consolidation with other efforts in this area:

Please work with us
on adding the cool features to CDO that you need!

EMF Tips #3: Why should I want to generate editors?

I thought about treating you with more of those beautiful flowers in Ed's garden but there's still material from our trip to Toronto. Thanks to Dave (Dave, the book, not the Google Bear!) and Kevin for organizing cool downtown and clubbing tours. And for demonstrating how dynamic IBM really is. Thanks also to Lynn and Kenn for showing us Ottawa. Damn, from getting almost one finger between Toronto and Ottawa on the map I deduced that it might be an hour's trip. It is not! Canada is sooo big.


So, why should I want to generate editors for my models? Have you ever thought about this? Or are you politely generating these editor plug-ins, just because it's possible? Or fun?


You might remember that I have 28 models in my workspace. Let's, for a moment, assume I generated 28 additional editor plug-ins into my workspace. A lot of code to maintain and we should be absolutely sure that this is (a) necessary and (b) appropriate!


To judge if it's necessary to generate editors on a per-model basis we need to compare the generated code of two such editor plu-ins. Interestingly, it boils down to a single difference in the initializeEditingDomain() method where the ItemProviderAdapterFactory for the model is added to the ComposedAdapterFactory. More interestingly, the editor will continue to function properly even if you remove this model-specific line! The reason is that the ComposedAdapterFactory delegates to a registry of descriptors which are contributed to the extension registry by the edit plug-ins. You see, it's clearly not necessary to have a generated editor per model.


And usually it's also not appropriate to have vast numbers of editors that are all alike. Model editors are a means to implement functionality that is orthogonal to the models. Things like ordering of nodes and properties, changing colors, fonts and so on are achieved by customizing the editor. I really don't want to duplicate all these UI-related, i.e. model-independent, aspects over 28 editors! And don't forget, your model can be used in other generated editors (other than the one that has been generated for this particular model).

All we need is a single generated editor for all our models.

Eventually we'll need additional editors for additional UI-related requirements, but not for additional models. The same arguments are certainly valid for the generated wizards. One difference between the generated editor plug-ins that I did not talk about, yet, is the editor and wizard markup in the plugin.xml. Our reusable editor would at least have to be prepared that it can be associated with different file extensions, depending on the set of deployed model or edit plug-ins.

EMF Tips #2: Tweaking my Genmodel

The major part of this month I've been on vacation in Toronto and spent a wonderful time with René, Ed and Frank. Ed's garden is as beautiful as one might expect and I was busy collecting evidence of that.


Too busy to keep up with my EMF Tips blog series. In part #1 we discussed ways to easily generate multiple models. Thanks for all the helpful comments.


This part focusses on tayloring and tweaking the outputs of a single generator model. The default Genmodel properties lead to generation of four plug-ins: model, edit, editor and tests.


We will always need the model plug-in itself but often we don't need all of the other three outputs, so how do we exclude particular plug-ins from generation?


The Genmodel has a properties category for each of the output plug-ins: Edit, Editor and Tests. Completely switching off the generation of any of these is as simple as deleting the respective Directory property.


The generator UI will immediately reflect this by disabling the respective Generate menu item. Even the Shift+Alt+G dialog from tip #1 will adjust accordingly.


The next part of this series will focus on the interesting question "Why should I want to generate editors?". For now, you'd know how to avoid it. Stay tuned.


I was just told that there are still three seats available for the Eclipse Modeling Code Camp training that Ed and I will be giving next month (starting October, 12th) in Munich. Don't miss this great opportunity to spend four days with us and become

the world's greatest modeler!

EMF is Awesome!

This is one of the conclusions in the first part of an article series I wrote for the german Eclipse Magazin. I already blogged about the included example application eDine. Now the article has been promoted to the JAXenter portal, where it can be read by everybody who's able to read German:

Modeling goes Enterprise I

In this article I elaborate on some internal details of EMF regarding scalability (see also my blog How Scalable are my Models?) before I dive into a detailed explanation of the CDO Model Repository.


The second part of this series will show you how to use EMF and CDO to build distributed, scalable and model-based application systems. The comprehensive example that will be included in that article is already available in the Eclipse CVS. I'll leave a note here when the second part is publicly available on JAXenter.


In case there's a translation geek out there, willing to help me translate these articles into English for a broader audience, please drop me a note. A seat in the CDO hall of fame is guaranteed :P

Modeling Stammtisch Details

Our poll for the upcoming Eclipse Modeling Stammtisch in Berlin was successful enough to arrange for a nice location and time. Jens v. Pilgrim sent me a proposal which I liked, too:

Prater Garten

Kastanienallee 7 – 9
10435 Berlin
(Prenzlauer Berg)

Begin: 18:30
End: Open

For the outside area it's not possible to reserve tables but they promised me that at this early time it'll be next to sure that we don't end up without a table for 25 persons. The rush hour there is only around 20:00.


Thank you, Jens, for the suggestion. We hope to meet you all there in two days...

Eclipse Foundation funds my Project

Some discussion has been going on about revenue models for open source projects and their committers. Many good ideas, some whining, and also some misconceptions. One of those was brought to my attention several times just recently by users of CDO and by some of my customers. They seem to believe that

The Eclipse Foundation funds my Project

This is simply not true, neither for my projects, CDO and Net4j, nor for any other Eclipse project. The Foundation's revenue, as well as the donations to the Foundation, are spent in a way that more or less suits all projects equally. Staff must be paid, servers operated, marketing be done, and so on.



All projects are responsible for their own funding. In particular the committers are either employees and paid by their employer (who'd better have a good business model for being able to continue to fund open source development) or so called individual committers, in which case they have to look after themselves for their funding or just do the work for their own gratification.


To make a project successful a great deal of marketing has to be done which often incurs additional costs such as conference fees and travel expenses. I tend to think that the community benefits from these marketing efforts in a similar way as from the usage of open source product itself. The more people are using a product the quicker it will mature to something really great. And the needed funding can be distributed among even more shoulders.



I'm clearly an individual committer and I'm usually working full-time on my two Eclipse projects, for more than five years now. This can and will only continue to work if enough users of the project results realize that nothing is really free:

Open source software is free.

Free like in freedom
but not gratis!

I hope this does not sound too much like whining. It's not intended to be like that. In fact I appreciate that more and more companies that reap benefit and revenue from using open source technologies realize the subtle but essential economic mechanisms that guarantee continuation of their business model. I'd like to take this as a chance to thank my own customers: It has always been fun to spend time with you being incredibly creative and productive to our mutual benefit!

EMF Tips #1: How the hell do I generate my 28 models?

Recently Ed pointed me to a "hidden" feature in EMF which I always thought I was missing. I take this as an opportunity to launch a series of EMF blogs with hints around EMF, starting with:

How the hell do I generate my 28 models?

In CDO and Net4j together we have 28 models, many of them being test or example models. It has always been a hazzle to regenerate them for new versions of EMF having been published. The best approach I was aware of is a manual loop like this:


I always wished there was a view with all genmodels so that I could select multiple genmodels and regenerate them with a single click. I had such a view in GenFw and even an incremental genmodel generator.

I bet you didn't know the default key binding Shift+Alt+G (M2+M3+G)? I didn't! Go figure:


A dialog opens that lists all genmodels in the workspace. The next page lets you select the sub models to be regenerated:


Before you switch to the second page be sure that all the genmodels selectedin page one can be opened with the genmodel editor without errors. Otherwise the wizard could indefinitely block the UI. Apart from this little lesson it works great and will spare me a lot of dumb effort in the future. Kudos to Marcelo for this neat (but somehow hidden) feature!