Understanding the Eclipse p2 Provisioning System
[img_assist|nid=3608|title=|desc=|link=none|align=right|width=120|height=160]p2 is the new provisioning system which will be provided along with the Eclipse Ganymede release on June 25th. This is one feature that I didn't really follow closely enough,so I was really happy when I called Pascal Rapicault to get an explanation from the project lead.Ian Skerrett has recently blogged about 10 reasons p2 is going to rock, and after reading this, I'm sure you'll agree.
James Sugrue: What does p2 mean?
Pascal Rapicault: 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.
Sugrue: And what exactly is p2?
Rapicault: At it's core, p2 does three things:
- 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.
- 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.
- 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.
Sugrue: Could you explain the dropins folder?
Rapicault: It's quite simple really. The platform ships with a default watched directory called dropins which is scanned on startup. Plugins added to this directory are installed if their dependencies can be satisfied. From an end user point of view, it is not much different than what you could do before. However behind the scene it is a full provisioning operation that is taking place, much like if you were installing from the UI. One advantage of this folder over the "plugins" folder is the more flexible layout it offers to organize your plug-ins, despite this we still recommend people to use the UI.
Sugrue: What is the reason for changing the update mechanism?
Rapicault: It is somehow all the reasons that are mentioned by Ian in "10 reasons p2 is going to rock". But more fundamentally it is because Update Manager did not follow the evolution of Eclipse in OSGi, RCP, etc. and the requirements imposed by entering those new spaces.
Sugrue: Is it difficult for plugin providers to use p2?
Rapicault:No since there is nothing to do. p2's backward compatible with the UM allow for people to keep on doing what they've always done. That said we still recommend everyone to generate p2 metadata when they are building update sites in order to offer a better user-experience to the final user. This can be done automatically when exporting from the UI and when building using PDE Build.
Sugrue: I've heard there were some difficulties as this was being developed and added in after EclipseCon. What happened?
Rapicault:There are several things at play.
First we (p2 team) lacked in communicating about the addition of p2 in the SDK and thus surprised people who were taking builds on a weekly basis.
Second is that the level of polish expected was simply not there, however we were caught in this chicken and egg problem where to mature more we needed to be integrated to get feedback but to be integrated we needed some level of functionality.
Third is also the change in workflows and simply things that we don't want to support because they are at odds with the new way.
Sugrue: Where can people go to find out more?
Rapicault: Well you can check out the Wiki page about p2. You can also read about it in the Eclipse help system or check things out on the newsgroup
Sugrue: What are the future plans for P2?
Rapicault: The plan will depend greatly on the interests of the contributors (p2 has contributors from several companies). Here are the few items that comes to mind, with no particular order or commitment :)
- Help people leverage p2 in their product
- Evolve the provisional API we have in place into a real API
- Tooling to manage repositories
- p2 metadata authoring tools
- Ability to store and retrieve artifacts in new formats like binary deltas, jar deltas, etc.
- Ability to duplicate installations and create installations from somebody else one
- Support for better desktop integration (e.g. desktop shortcuts, registry keys, etc.)
Sugrue: What else do you see as being important in the Ganymede release?
Rapicault: In this release I have not had much time to follow what was going on outside of the platform. However, in the platform I can see a few things:
- API Tooling is important because it represents an new milestone in helping the community author well behaved component. For example it answers questions like: am I breaking my API, is the version number of my plug-in correct, etc.
- Equinox Security, which now allows to protect from running malicious code and also provides a true secure storage.