Creation Review

Type
Creation
State
Successful
End Date of the Review Period

Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.

Proposal

Oomph

Thursday, March 27, 2014 - 09:39 by Eike Stepper
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Project
Parent Project
Proposal State
Created
Background

The Eclipse IDE has become increasingly powerful over the years. With this power comes an increase in complexity that becomes more and more difficult for users to manage.

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.

 

Scope

The Oomph project provides tools that automate the provisioning and management of project-specific IDEs and workspaces, as well as other tediously repetitive tasks.

Description

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
Why Here?

Oomph provides technology that is highly complementary to the Eclipse Platform and we expect it to be broadly adopted.

Future Work

Future work will be primarily driven by community feedback.

Project Scheduling

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.

Project Leads
Committers
Julian Enoch (This committer does not have an Eclipse Account)
Interested Parties
  • Ericsson
Initial Contribution

The initial contribution is the implementation of the frameworks and tools described in the description section, refactored from the code base currently hosted in the CDO project's Git repository. No third-party libraries are required.

Source Repository Type

Sounds great - would love to use Oomph right away, what will be the schedule for initial downloadable bits ?

I'll be happy to serve as an additional mentor if needed.

Definitely eases the entry barrier even for other than Eclipse targeted projects. We already started to adopt Oomph to ease setting up a development environment for our Eclipse RCP application!

Creation Review