Is P2 ready for Eclipse?

Posted by Alex Blewitt on May 21, 2008 09:30 AM

Community

Java

Topics

Tags

Eclipse ,

Eclipse RCP

The Eclipse update manager allows an Eclipse install to be updated from one or more remote sites. To date, it's been the most usual way of upgrading point releases (e.g. 3.3.0 to 3.3.1) as well as installing new features. However, it had a number of well-known issues, such as the inability to update the eclipse executable or deal with mirror failures.

To solve this, the seeds of a new update mechanism were sown at EclipseCon 2007 in a BoF session. And so the subsequently named Provisioning Platform, or more simply P2 was born. Since then, it's graduated from the incubator, and made its first debut in 3.4M5.

Unlike the previous Eclipse update manager, P2 is generic to allow both bundles and non-bundles to be updated. This opens the way for other systems (such as Wascana, a MinGW based bundling of the CDT to enable GNU development on Windows) to use P2 to update DLLs and other executables that form the distribution.

P2 formalises the concepts of an Installable Unit (which is really metadata about the thing that can be installed, rather than the thing that will be installed; think a Maven pom.xml) as well as the artefacts that will be installed (whether that's bundles, executables, libraries etc.). Furthermore, these are stored in separate locations so that an update system can quickly determine what there is to be installed (and whether dependencies can be met) without having to download the artifact itself.

Downloads are handled by the Eclipse Communication Framework. It's also possible for the artifacts to be compressed using one of several different algorithms (pack200, tar.gz) and for multi-threaded downloads spanning multiple mirrors to be used. And whereas the previous update manager would fail if the update site experienced a problem during the download, P2 will automatically retry a different mirror in order to find the data. You can even download a 5Mb installer that will install Eclipse and all its plugins.

It's clear that P2 solves many of the glitches that the old Eclipse Update Manager had, and has received a number of positive reviews. However, whilst a lot of work has been going into the underlying infrastructure, the UI has only recently been developed and still is a work in progress. Furthermore, P2 has now edged out the old Update Manager, and despite the 3.4M7 plans to ensure backward compatibility with update manager, it's clear that not all is well.

One of the key features missing is the ability to install into different extension locations. This is something that many use to allow different subsets of functionality to be installed, particularly for cases where a shared set of plugins (like Subversive or Subclipse) might be installed between Eclipse installs, as described by IBM's DeveloperWorks article. This has led some to petition for the Update Manager to be restored, and a few negative impressions so far, not to mention the fact that the installer doesn't work on Mac OS X.

It's clear that P2 is the way of the future; there are many benefits over and above the old update manager. But it's also in need of testing, and with last week's 3.4RC1, the clock is ticking to Ganymede's release next month. Do you think P2 can be made ready and stable in time?

1. Back to top

   Equinox_p2 Repise

   May 21, 2008 12:50 PM by Fred Grott

   Alex I am doing a very informal test on Eclipse 3.4RC1 Equinox use cases for migration. Will be posting some informal things I find to blog tonight. Thanks for the link it is appreciated.

   Reply

• Older >