Equinox p2 M1

Milestone 1, as the name implies, is our first step towards a new provisioning system for Eclipse. We have hit most of the major items on the M1 plan except for roll-back support. Most importantly however is that the meta-goal of self-provisioning is at hand. That is, the new provisioning support allows people to install and manage the Eclipse environment they use to develop the provisioning system itself! AKA "eating your own dog food".

Note that we decided to replace M1 with an M1a that has a few key fixes and is based on the Eclipse 3.4M1. All of the discussion here still applies but the content references etc relate to M1a.

So, what should you expect from Milestone 1.

• First, don't get your hopes up too high. Most of what we have accomplished is buried well under the covers. We have been laying a new foundation for a flexible and extensible provisioning platform.
• With M1 you are able to install and uninstall individual bundles as well as groups of bundles and whole Eclipse product installs (e.g., we supply a packaging of the Eclipse SDK).
• You can start from scratch and install a complete Eclipse SDK and then add to it or remove from it using the agent. Note that since the supplied SDK is just a packaging of 3.3, it does not include the new provisioning support. Of course, you can use the provisioning agent to add provisioning support to the SDK!
• The Admin UI is just that, a UI intended for our developers/repository administrators, not end-users. The end-user UI will start to take shape during M2.

New and Noteworthy

In a sense it is all new... In any event, here are a few highlights of the new infrastructure:

• There is a little RCP application you can use to create and manage your profiles. The same capabilities are also exposed through a text console and the same perspective can be added to the SDK. Oh, and you can call the same operations from code via API.
• The agent allows you to manage the profile you are running as well as other profiles.
• You can create/manage multiple profiles and all installed bundles are downloaded only once and shared between the different profiles.
• The new support is a complete replacement for Update Manager. Notice that in the fully functional Admin UI application there are no Update Manager bundles.
• There are simple, lightweight APIs for manipulating and managing profiles.
• The new provisioning support includes tools to generate metadata based on existing features, plug-ins and Eclipse installations. In fact, that is how the metadata in M1 was created.

Getting started

Sound interesting? For those who want to learn more, try it or get involved, we've put together a series of guides that will help you along the path. These documents will continue to fill out and evolve with the provisioning support.

• Getting started with M1
• Equinox p2 Admin UI Users Guide
• Equinox p2 Console Users Guide
• Equinox p2 Getting Started for Developers

Gotchas

The Bugs n Blunders page details most of the current pitfalls and issues that you are likely to see in using the new provisioning support.

Speaking of bugs and blunders, it is very early days for the provisioning support and the road will be bumpy in spots. Your ideas, insights, bug reports and contributions are what will make this effort a success. Please direct comments to the equinox-dev@eclipse.org mailing list and bug reports to the Eclipse/Equinox/Incubator bugzilla bucket (use [prov] in the summary line).

It's worth noting a few issues here just to set the context.

• The Admin application comes as a pre-installed product in a zip file. The current install structure includes several hard-coded, absolute paths. As a result, the Admin UI must be unzip'd directly at the root of your C drive.
• Which raises the next issue. Currently we are only delivering Windows. For the most part this is just because we have not set up the complete build infrastructure (needed because we have absolute paths) but there is also ongoing work in the area of shared installs that needs to be integrated.