Consider the steps involved in setting up a fresh Eclipse development environment to work with the source code of a particular version of a specific project:

The instructions for all these steps must be well-documented and generally evolve from release to release. As such, one should consider the following salient questions: The most fundamental question is, why is anyone doing this manually? The overall process is tedious, error-prone, and time consuming, i.e., it's a complete waste of human resource. With Oomph, all these instructions are formalized as setup tasks that are performed automatically.

In addition to the project-specific setup process, each user typically has her own personal favorite tools she wants installed as well as has her own personal preferences, such as key bindings, she wants uniformly applied to each installation and workspace. With Oomph Setup, this too is formalized and automated.

The process of setting up a development environment involves two phases. The first, or bootstrap phase, involves installing a functional product on disk. Using the traditional manual approach one achieves this goal by as follows:

The second phase involves activities performed in the running product itself:

To automate this setup process, Oomph provides the following:

Oomph helps ensure that each developer works with the same uniformly-provisioned development environment and that each user has her personal tools and preferences uniformly available across all installations and workspaces. Note that Oomph can be installed into an existing IDE, i.e., one not installed by Oomph, via Oomph's update site or via Oomph's site archive.

To understand how best to exploit Oomph in order to save time and spare aggravation, some basic concepts need to be well understood. Automation is achieved by specifying setup tasks organized into scopes stored in resources.

An important footnote is that Oomph makes heavy use of bundle pooling so it highly disk-space efficient to install many products and provision many target platforms because they can all share a common bundle pool such that for each installable unit, there is only on jar file on disk. Not only is this space efficient, it also dramatically improves installation and provisioning performance because once an installable unit is in the pool, it never again needs to be downloaded from the Internet.

This document provides a general overview of the concepts that underly Oomph's Setup model: Context