Consider the tasks needed each time a user sets up a fresh development environment to work with a particular version of a specific project:
Install a project-specific IDE with appropriate tooling.
- Which tools need to be available for editing, compiling, debugging, and testing?
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 the bundle and feature versions.
- When should the major, minor, and micro versions be incremented?
Manage a clean, warning-free workspace.
- How to avoid workspace-scoped preferences which must be maintained independently of the bundles and features?
- How to effectively manage consistent project-scoped preferences across a multitude of bundles and features?
Install personal tools.
- What additional favorite tools need to be installed?
Manage personal preferences.
- How to enable things such as personalized key bindings to make Eclipse more comfortable?
Tools that address these problems are badly needed but bloating the Eclipse Platform is something to be avoided.
We propose the creation of the Oomph project to provide tools to enhance the user experience of the Eclipse IDE.
The Oomph project provides tools that automate the provisioning and management of project-specific IDEs and workspaces, as well as other tediously repetitive tasks.
The Oomph project provides tools based on extensible frameworks, packaged as fine-grained features that allow consumers to pick and choose. The basic building blocks include the following:
- An EMF model for manipulating Eclipse preferences.
- An EMF model for specifying predicate-based logical sets of projects.
- An EMF model for enforcing profiles of project-specific settings (driven by the predicates model).
- An EMF model for inducing dynamic working sets (driven by the predicates model).
- An EMF model for managing modular PDE target platforms (based on composable targlets).
- An EMF model for describing IDE configurations.
Based on these building blocks Oomph initially provides the following tools:
- A tool for browsing the Eclipse preference structure.
- A tool for maintaining consistent project-specific settings across a large number of projects.
- A tool for creating dynamic working sets that update automatically as new projects are added to the workspace.
A targlet container that seamlessly integrates with PDE's target definitions and provides the following advantages:
- Dynamic composition
- Lazy resolution
- Resolution-failure resilience
- Global bundle pool
- Bounded version ranges
- Optional workspace provisioning
- A tool for managing bundle pools, including purging unused artifacts and repairing damaged artifacts.
- An installer for installing an IDE from a selection of project-specific configurations, augmented by user-specific configuration.
- An engine for keeping an IDE consistent with its specified configuration.
- A builder for managing bundle micro versions and feature versions relative to a baseline, augmenting PDE's API Tools.
A selection of small conveniences:
- Launch configuration decorators
- Context-sensitive manifest opener
- Copyright-consistency management
- Project copier
- Git command-line integration
- Launcher for platform-specific file explorers
Oomph provides technology that is highly complementary to the Eclipse Platform and we expect it to be broadly adopted.
There are no legal issues because the initial contribution is currently hosted in the CDO project's Git repository.
Oomph releases will align with Eclipse's annual release train. The initial contribution as well as builds are already publicly available at Eclipse via the CDO project.
Future work will be primarily driven by community feedback.