I came to Eclipse in 2004 and I was experienced in the area of model repositories and at that time I discovered the Eclipse modeling framework which seemed a perfect match as a front-end for my model repository. So, I decided to open-source this repository technology at Eclipse. It is called the CDO Model Repository and since these days I am the lead of that project, a committer on many other projects. That is how I got involved.
2. CDO – yet another Eclipse acronym. I wonder if you could explain what CDO stands for.
Yes. CDO stands for Connected Data Objects. The reason is that the model, the objects – it behaves like a database, but it has a bidirectional access. So, the objects you check out stay connected to the repository and get notified by the repository when others change them. So, in other terms, it is a distributed shared model repository framework.
3. How did your work in the modeling tools come to create Eclipse Oomph and what does Eclipse Oomph do?
Eclipse Oomph is a new installer and provisioning technology and it started as a very small release engineering component of my CDO project. CDO has grown over the years and we access many different kinds of databases, we deal with different network transports, a lot of technologies. Internally, we use API baselines and all that stuff. Then, every new committer on the project, new contributors, they have to configure so many things and I had to write so much documentation to make it possible to understand what to do, that at some point I said “No, I am sick of writing this documentation. It is always out of sync”. It started with a couple of scripts actually that automated this setup process and then I demoed that to my best friend Mr. Ed Merks. He is the leader of the Eclipse modeling project and he said “Oh, I want that for EMF too”. So, we sat together and started to make it a little bit more flexible so that it could work with CDO and EMF, and while we were doing that, we realized that it could be very interesting for other projects, too. So, we kept working on it, made it more and more flexible and I think that process went on for one and a half years that we worked on Oomph how we started to call it then. Actually, the name was the idea of Mr. Merks. At some point, I think it was roughly half a year ago, we transferred all the code base into a separate own project at Eclipse and that is the Oomph project.
4. Does Oomph stand for anything or is it a play on a word?
Actually, I think it is an English word. We have seen that in an old newspaper where Mitsubishi announced – they titled it “Mitsubishi puts oomph in their Eclipse spider” and that means making the engine more powerful.
5. And so the idea is that it makes your Eclipse developer environment more powerful?
Yes, exactly. In the end, we want to allow developers to focus on their development work and not on setting up their development environment for days.
First, you are right. Since milestone 5 of the Mars release train, the Oomph runtime, so the provisioning engine, is installed or comes with all of the EPP packages and for users, the most prominent benefit is that we have a preference recorder so all the user preferences that they change in the preferences dialog they get recorded into a user profile that we store in their home folders and when they create new workspaces or new Eclipse installations, our setup engine pulls in all these preference tasks and applies their settings consistently to all the workspaces. So, they no longer have to remember them or import/export them which was always a little bit of a hassle. That gives a smoother experience when they switch workspaces and so on. But these preference tasks are just one example of tasks. We have many different implementations. They can configure their own favorite tools like editors – I know Ed Merks, for example, always uses his vi editor which personally I do not understand, but that is a different topic. That is all automated through Oomph.
Alex's full question: So, it allows you to have multiple workspaces that behave and look in the same way. But you were talking about the project specifics that originally drove you to do this in the first place with CDO. How does Oomph help provision projects and setup something on a per-project basis as well as a workspace basis?
We have this setup engine which is deployed into the running IDEs and additionally we have created an installer executable – that is a separate native executable. It is basically an SWT OSGi application. On Windows it even comes as a self-extracting native executable now. It uses the same engine and the user can pick project profiles from so-called project catalogs, one or more of these profiles, and they will be associated with specific workspaces and the installer can bootstrap the entire Eclipse IDE installation, launches it then and that is typically a small number of setup tasks that get executed, typically P2 director tasks that install plug-ins and so on. Once that new IDE is bootstrapped, it is launched by the installer and then the embedded runtime in the IDE picks up the rest of the tasks and executes them within the workspace. For example: clones the git repositories; imports the projects; sets up the target platform; configures working sets and everything that is needed. It is up to the projects how they define these profiles that the user can pick later.
Alex: So it is almost like a recipe that says: “Here are the projects to import, here's how to set the preferences up, here's what key bindings I like. Make it just so!”
Exactly.
Yes, definitely. So, we ship a couple of wizards that make it easier to create these initial profiles. They're template driven, you have to answer a couple of questions: namespaces of the project, stuff like that. Of course, some projects are naturally more complicated, more complex than others, but it is comparatively easy to start with these wizards and then, by drag and drop, you can link these new profiles into our project catalogs and you can immediately use our installer to execute these profiles and bootstrap new IDEs. Once you've done that, you stay in that IDE and try to evolve these setup descriptions.
I think, to date, our project catalog contains about 30 project descriptions of Eclipse projects. Oomph supports multiple project catalogs – currently we have one for Eclipse.org projects and one for GitHub.com projects. The number of profile descriptions is constantly increasing, as people get more aware of what Oomph can do. Initially we have created some profiles for other projects so that the project catalog is not empty initially and now we are trying to move over the ownership of these profiles to these projects. Most of the projects are happy about that and now want to try to learn how to maintain these descriptions themselves. It's not very complicated. Currently, one of our main tasks is to improve on the documentation which is of course a very enjoyable thing, but it is needed in all that. I think it makes a pretty good impression and we hope that we get more and more of these profiles in our catalogs.
Alex: Could they be used to launch projects like at the Apache Foundation where they have a well-known layout and to be able to import those and materialize workspaces at Apache as well.
Definitely. People have already had some nice ideas. For example, on conferences like here, it would be nice for the tutorials to have a setup description so that people can, within one or two minutes, bootstrap their tutorial environment.
11. If people wanted to get involved in Eclipse Oomph, where would they find out how to do that?
We have a wiki page at Eclipse and that lists among the main features also all the communication channels. So, it describes how to install an Oomph environment itself. So, of course we have a profile description to bootstrap ourselves. That was the main reason initially and then it is easy. We have a news group, we actively monitor it. Typically people do not have to wait longer than a couple of hours when they have questions. That is quite a vibrant community that is starting to evolve around Oomph now.
Yes. I mean one thing's clear, since Oomph is in all the packages, everybody will more or less use it, whether they realize it immediately or not. Of course, they can switch it off in the preferences if there is something that does not match their environment or so, but yes, I guess that the embedding into the packages will boost the usage of Oomph, of course.
Alex: Eike Stepper, thank you very much.
Thank you.