Eclipse has Oomph

Consider the tasks needed each time you set up a fresh development environment to work with a particular version of a specific project:

• Install or update an Eclipse product with appropriate tooling.
  • Which tools need to be available for editing, compiling, debugging, and testing the project's sources?
• Materialize the appropriate bundles and features in the workspace.
  • What needs to be imported into the workspace and from which source code repositories?
  • How are those bundles and features organized into meaningful working sets?
• Materialize the appropriate target platform.
  • What needs to be in the target platform to compile the bundles and features, as well as to launch the associated tests?
• Manage a clean, warning-free workspace.
  • How do you avoid workspace-scoped preferences which must be maintained independently of the bundles and features?
  • How do you effectively manage consistent project-scoped preferences across a multitude of bundles and features?
• Install your personal tools.
  • Which of your favorite tools can't you live without?
• Manage your personal preferences.
  • How do you enable things such as key bindings and color schemes that make Eclipse comfortable for you?

These tasks need to be well documented and evolve from release to release for each and every project.

• Who writes and maintains the instructions for these tasks?
• How many people need to follow these instructions and how often?
• How do your contributors find the instructions for your project?
• Why is anyone doing this manually?

With Oomph you can manage all this more effectively by formalizing the setup instructions so they can be performed automatically with the click of a button. In this article we'll focus on the user's experience as opposed to how authors create setup descriptions for their projects. For the end users, Oomph provides a wizard to drive all aspects of the provisioning process. For provisioning new installations from scratch, Oomph provides an RCP application to launch the installer wizard; it's downloaded and unzipped just as for any Eclipse Package download. Launching that results in the following:

The initial page allows the user to choose a product to install from one or more product catalogs. The Eclipse product catalog is generated from the Eclipse Packaging Project's p2 repositories, so it allows users to install any version of any product they'd normally find on Eclipse's main download page. Oomph's underlying infrastructure supports bundle pooling for all aspects of the installation (and, optionally, even of the target platform), i.e., when installing multiple products using Oomph or when provisioning multiple target platforms, the installations and target platforms can share all the common bundles and will download each bundle only once. This dramatically reduces disk space as well as speeding up installation and target platform provisioning time. Of course one can disable bundle pooling to produce an installation exactly like you get with an unzipped package download. You can also see there is a dialog to manage the bundle pools.

This allows one to manage the pools and agents, do garbage collection of unused bundles, and even repair damaged bundles by downloading the same version of that bundle from the internet. With Oomph the user has flexible control.

Note that for those familiar with the early prototype version of Oomph, the current architecture is dramatically more flexible and less invasive. You'll notice that on the next page of the wizard.

On this page you can select projects that have provided Oomph setup descriptions for provisioning a workspace to work with the source code for that project. But this aspect is optional, i.e., you can use Oomph only to install a product, or to install a product as well as provision a workspace for that product to use. If you double click on the Oomph project, you'll see it's added to the bottom of the dialog, where you can choose which stream of the project you'd like to have in the workspace. Of course Oomph only has a master stream at this point. Oomph is designed with composition in mind, i.e., it's possible to provision multiple projects into one workspace. This is definitely a technical challenge for which Oomph provides a more flexible, high-performance target platform implementation. Proceeding to the next page, the user is prompted for information needed to complete the product installation and the project provisioning.

Most of the choices made are recorded, so the very first time you install something, you'll have quite a few choices to make, but on subsequent reuse, that's dramatically reduced. Proceeding to the confirmation page, you'll see the follow:

These are the tasks that will be performed to produce the installation and to preconfigure the workspace for the projects being provisioned. Tasks can be disabled, if desired, but during this initial installation most are absolutely required. Proceeding beyond this page will kick off the installation process.

The first time users install a product, this process can take quite long because a large number of bundles need to be downloaded from the internet, but subsequent installations can take as little as 20 seconds. When the process completes, the installed product will be launched and any remaining aspects of the installation process are performed in the launched product. The running product will automatically bring up the installer wizard to show progress on the remaining tasks.

In this article, the Oomph project itself was selected for provisioning, so the tasks include cloning the Git repository, provisioning the target platform needed by the Oomph source projects, and defining working sets to organize those projects. Upon completion, the resulting workspace looks as follows:

Note that because Oomph's artifacts require tools such as EMF's generator and Ecore Tool's graphical editor, those tools have already been installed along with the product.

That's it, the users can now work on the Oomph project source the same way as an Oomph committer, and can commit their changes to Gerrit for review.

Another exciting aspect of Oomph is its support for managing, among other things, personal preferences. The editor for user tasks can be opened via the toolbar and then the Eclipse preferences dialog can be opened via the editor's toolbar contribution:

All preferences changed will be recorded as tasks, and those tasks will automatically be performed in each Oomph-installed product. So now users can decide which workspace-specific or installation-specific preferences they want universally the same in all their installations. In addition, any type of task can be authored in the user tasks editor, i.e., additional p2 tasks for installing a user's personal favorite tools into each and every product.

Revisiting the initial question of "the tasks needed each time you set up a fresh development environment to work with a particular version of a specific project", with Oomph that boils down to launching the wizard, choosing what you want and where you want it to be, and letting Oomph do all the rest. The expensive parts of the installation and provisioning process are generally those that involved internet access, i.e., downloading bundles and cloning repositories, so even if those take quite long, they can run unattended, while you focus on real work.

For more information you can read the project proposal and if you want to try it, you can follow the instructions in the wiki.