Oomph changes the way you handle multiple eclipse installations

Oomph is a great technology available with the Mars version of Eclipse IDE.

I work on many Eclipse projects and projects based on Eclipse technologies. I have of course the project I work on for our customer (daily job), but I also try to contribute to different open source projects and I also like trying new stuff and playing around with new technologies.

All these different tasks require different Eclipse installations. When I experiment with Xtend I use “Eclipse IDE for Java and DSL Developers”. Sometime I need an IDE with Maven support, but not always. After the EclipseCon I just installed an Eclipse supporting Gradle and Groovy development.

So far, I have never tried to install everything in the same Eclipse IDE. I feared the RAM consumption, overloaded menu trees and an IDE containing too many plugins. So I ended up with a folder containing different eclipse installations (one for each domain):

Such a folder structure both consumes disk space and maintaining each installation is time consuming and repetitive. Take the Mars.1 update release as an example. I have so many bad reasons for not updating my IDEs: it is boring, it takes time, it takes disk space, ….

At the last EclipseCon Europe I finally found the time to get into Oomph and the great new is: with Eclipse Oomph (a.k.a. Eclipse Installer), I am convinced that I can do much better than in the past.When you look at a classic Eclipse installation, it looks like this:

I wasn’t really aware of it, but this folder contains the result of 3 different mechanisms: an Eclipse installation containing the executable and some configuration, a p2 bundle pool where the plugins are effectively stored and a p2 agent that keeps everything together by storing the installation details into profiles. Oomph takes advantage of the flexibility offered by P2 and does not create a standalone installation.

The main advantage of this approach is that the Bundle Pool can be shared across your Eclipse installations. This drastically reduces the disk space for your eclipse installations. It also reduces the time it takes to install and to update each of your eclipse installations.

When you install something in one IDE, files are stored in the bundle pool. Installing the same plugin again in another IDE is straight forward. Oomph just updates the profile and reuse the files already present in your bundle pool.

In addition Oomph is all about setting up your Eclipse environment. Automation is the key word here. You can easily define setup tasks that are shared across all your Eclipse installations. This way you no longer loose time with modifying the default Eclipse settings to obtain the installation you want.

The Oomph approach is really great. In my opinion you can now have one Eclipse IDE setup for each project you work on. On this blog I will continue to explain the advantages of Oomph and what it changes when you work with it. The Scout team will of course also contribute a setup task to facilitate contributions on our framework.

Feedback: please use this forum thread.

Project Home, Forum, Wiki, Twitter, Google+