Remediation Support, Top Eclipse Kepler Feature #2

In one week, on June 26th 2013, Eclipse Kepler will ship. To prepare for the release I’m counting down the Top 10 most interesting features according to me. Number 2 on my list is close to my heart – the Eclipse Provisioning Platform (p2) – and the new features it supports.

The Eclipse Provisioning Platform (p2) has been responsible for installing and managing Eclipse plug-ins for over 5 years now. With a large ecosystem of components with complex dependencies, installing plug-ins is more involved than simply downloading and unzipping. Often multiple components may provide a suitable API, and finding the best (optimal) set of plug-ins is actually a hard  satisfiability (SAT) problem.

The value p2 brings is that it handles dependencies and other integration problems at install time instead of at runtime – if you can install it, you can run it. It uses SAT4J for solving the SAT problem and finding the optimal solution. Unfortunately this leads to many headaches when trying to install complicated software stacks. The provisioning platform will often present cryptic error message and users are left with no way forward.

We’ve investigated this problem in the past by trying to present the error message in a more meaningful way, or by giving the user some idea of how to ‘fix’ the problem. During the development of Eclipse Kepler, Pascal Rapicault approached it from a different angle.  Instead of trying to comprehend the SAT4J error message, p2 will now proactively search for alternate solutions to help you proceed.

For example, p2 may now suggest that you un-install or upgrade a conflicting component. Or, if you are trying to install a number of components and only a few of them cannot be satisfied, p2 will allow you to proceed with the ones that can be installed.

The Remediation Wizard is automatically invoked whenever a solution cannot be found. It’s enabled for both the standard p2 UI as well as the Market Place Client (MPC). While this will certainly improve the user experience, it also should help the ecosystem since it’s more likely a user will now complete their install with their existing Eclipse base, instead of always starting from a fresh Eclipse Download.

In addition to the remediation support, Pascal also added migration support for ‘shared installs’. When running Eclipse in read-only mode – as is often done on *nix systems – Eclipse automatically enters ‘shared install mode’. This is because several users often ‘share’ the same install base. When users install additional plug-ins, they are installed locally, for that user only. Problems arise however when the base is upgraded – in fact, when this happened the updated Eclipse would simply ignore the users local plugins.

In Eclipse Kepler, when a base install is updated in a shared install situation, the users will be presented with a new migration wizard to help them install and keep using their local plug-ins.

With these changes we hope to see a lot fewer of you on the bug reports :-).

For more Eclipse Tips & Tricks and for my Eclipse Top 10, follow me on Twitter.