Eclipse Workspaces with Oomph

Oomph is not only about eclipse installation, it changes also the way you organize your workspaces.

Multiple Eclipse installations

In my previous blog post I have explained why you can have as many eclipse installations as you want (an installation is 20 MB, the bundle pool is shared and maintenance like updates can be automatized). This solves another problem I had: I have a lot for workspaces and I never knew with which eclipse I should open it.

The basic Idea is simple: a workspace containing a scout application should be opened with “Eclipse for Scout Developers”. My Xtend experimentations should be opened with “Eclipse IDE for Java and DSL Developers” and so on… But when you start to have several versions of each IDE (if you consider some of the Milestone releases, there are a lot of Eclipse versions) you have no chance to remember it properly.

It gets worth when I try something different. I need to remember in which version of the “Eclipse Modeling Tools” I did install the MoDisco plugins to try this project out… (Was it Luna? Was it Mars?). The same goes for the Eclipse B3 tools I have installed this tool to create a maven repository for Mylyn Wikitext. Where did I install it? It is a mess!

The Oomph way

When you start to work with Oomph, you control where Oomph will install and checkout all the components needed for the setup. What is particularly interesting is that you can work with patterns that are reused for each of your installations. I have decided to stay with the default setting:

  • Installation location rule: “Installed in a uniquely-named folder inside the root folder”.
  • Workspace location: “Located in a folder named 'ws' within the installation folder”.
  • Git clone location rule: “Located in a folder named 'git/<repo>' within the installation folder”. 

With those settings, the structure I get for each of my installations is the same:

Git clones per repositories

First I wasn’t really convinced by the idea of checking out the Git Repo each time. Now I have reconsidered it:

When we were using SVN we had a checkout in each workspace. It makes sense and we were happy with it. Applied to Git the same reasoning means that we need to clone the remote repository for each workspace. (A checkout corresponds to a “Working Tree”).

It takes disk space, but it solves problem you get when you share a git repos between multiple Eclipse Workspaces. The IDE gets lost with switches between branches that are too different. With Eclipse Scout we have a good example of different branches: our Mars branch contains Eclipse Bundles (OSGi) and our Neon Branch contains plain maven projects.

Git 2.5 has introduced the possibility to have multiple working trees for a single repo. When this feature will be available in JGit/EGit, the situation can be reconsidered. In the meantime, having each git repository cloned per workspace is a good solution.

New working workflow

I really like the workflow proposed by Oomph. The structure created by Oomph “eclipse/git/ws” makes sense. During the Oomph tutorial at the EclipseCon Europe, Wayne Beaton added that he started to consider this structure as something “really transient”. This is absolutely true for project you occasionally contribute to. You set up an eclipse for the projects you need; you contribute a patch; you remove the corresponding eclipse installation (once your patch is accepted).

It is possible to work like this, because recreating the installation if you need it again only takes a couple of minutes. This is similar to running a VM in the cloud: you no longer take extra care of it as you did with your company server, because when you no longer need it or when it is broken you kill it and you start automatically a new one. It is the same principle with your eclipse installation.

Oomph for Eclipse Scout

In the Eclipse Scout team, we see Oomph as a possibility to reduce the barrier to entry for external contributors. With oomph the knowledge required to start contributing a patch is reduced and the time it takes to do the setup should also be smaller. We have started to use Oomph inside our company and we hope to be able to share it with our open-source community in the next weeks.

Feedback? Please use this thread on our forum.

Project Home, Forum, Wiki, Twitter, Google+