Features and P2 in eclipse platform

An Eclipse feature project contains features. A feature has a name, version number, a software license and contains a list of plug-ins and other features which can be understood as a logical unit.

A feature is described via a feature.xml file in the Eclipse feature project.

Features are used by the Eclipse update manager, the build process and optionally for the definition of Eclipse products. Features can also be used as the basis for a launch configuration.

p2 doesn't actually stand for anything in particular. Well, the first P does stand for Provisioning, but the second P is up to the users.Most people tend to go with Platform.

At it's core, p2 does three things:

1. It replaces the  update manager with simplified workflows. So it will be a lot easier to install new plugins and keep them managed. In the future, we hope to work on providing tighter desktop integration like Windows registry keys and the like. So we're replacing the whole Help>Software Updates menu entry. Our UI shows the Installed Software and the Available Software. And you can also turn on Automatic Updates, which is pretty useful if you want to stay on the cutting edge.
   
2. The second thing that we provide is something called Bundle Pooling. Although you mightn't know it, this is a feature that you've been waiting for. It means that you can share plug-ins across multiple Eclipse instances. This really saves you with the disk footprint caused by your Eclipse installation, but also with VM supporting shared classes it can help with the memory footprint. Before p2, every Eclipse application had it's own plugins directory. Now there's no duplication of content - p2 takes care of ensuring that the bundles needed by the various applications in the system are present in the bundle pool. This is much better than the previous Extension Locations approach where the update done in one configuration of Eclipse could break another one unnoticed.
   
3. Our motto is "if it installs it runs". To achieve this, the dependency analysis is realized on an abstraction of the dependencies found both in bundles and features thus guaranteeing that all the necessary elements to run the system are available. In fact, because we are using the Pseudo boolean capability of SAT4J, we are guaranteed that if a solution exists it will be found and it will be optimal based on the fitness function we provide.