If you followed the catchy title because you were fearing that the CDO Model Repository project could be discontinued, well, then I've chosen the right title. Let me elaborate by starting with a little anecdote:
During a previous conference I talked about how CDO can transparently turn your file based, isolated EMF applications into a distributed cloud of nodes, all collaborating on a central shared model, immediately seeing all the changes that are committed to the repository by other clients.
I was asked what would happen when, due to network failure, a client gets disconnected from the server. Would it be able to continue working in a disconnected mode? At that time I answered that the C in CDO is for Connected (Data Objects) and that we, for this reason, do not offer an offline mode.
Well, while that caused a grin here and there it was kind of polemical and I must say that I've always understood the industrial relevance of being able to work offline. The real reason for not having this mode in CDO has always been the tremendous cost to develop it properly. As an individual full-time committer I just couldn't afford this investment on my own.
But exactly this has changed since and my new main sponsor has given me the opportunity to develop the cool new offline mode for CDO. In fact it is not only a mode, optionally provided on the client side. More exactly it's a new type of a cloned repository. This clone is continously being synchronized with a master repository and can almost be used like a normal repository. Clients are almost not impacted, normally they do not even realize whether the clone is online or offline.
The major challenge wasn't so much the background synchronization of the clone or write-through commits of clients while the clone is online. It turned out that committing to the clone during offline periods and pushing these changes to the master later is even more complex. I'm tempted to slip into the details of the technical solution that I implemented, but the whole purpose of this article is to allure you to my exciting EclipseCon talk:
The talk is on Wednesday, starting at 14:30 and I'm going to augment the beginners' overview of the technology with a preview of all the new and the cool stuff that we'll be delivering with the upcoming CDO 3.0 in Helios. And I'm also going to explain why the new offline mode has coincidentally lead to the introduction of branching and merging support in CDO, as well.
I'm looking forward to meet you all (again) in Santa Clara!
Friday, March 19, 2010
Monday, November 2, 2009
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:
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:
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:
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:
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!
on adding the cool features to CDO that you need!
Wednesday, September 30, 2009
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).
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.
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.
Tuesday, September 29, 2009
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
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!
Saturday, August 22, 2009
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:
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
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
Monday, August 17, 2009
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:
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...
Prater Garten
Kastanienallee 7 – 9
10435 Berlin
(Prenzlauer Berg)
10435 Berlin
(Prenzlauer Berg)
Begin: 18:30
End: Open
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...
Friday, August 14, 2009
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
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:
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!
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!
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!
Subscribe to:
Posts (Atom)
Posts
