[eclipse-dev] p2 update

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

We thought it would be useful to give
a quick update on the state of p2 integration for the Eclipse project team.
 After a bumpy road last week with integrating p2 into the build,
we now seem to be in good shape.  This week's build is good, and if
you already downloaded last week's build you can upgrade it to yesterday's
build using the following update site: http://update.eclipse.org/eclipse/testUpdates/.
 The various test failures last week relating to p2 and the changes
in the test framework have been sorted out, and we believe the remaining
test failures are not p2 related (please enter a bug against p2 if you
believe otherwise).

This week we are working on further
improvements in the build framework around p2, as well as producing p2-enabled
versions of the SDK for the remaining platforms. We hope to have this all
sorted out by the end of the week.  These remaining changes should
not have any visible effect outside the build process, apart from hopefully
faster build times due to eliminating duplicate work in the builder.

The eclipse dropins folder can be used
as a replacement for dropping extra bundles into the plugins directory,
links directory, or extension locations. More details on the dropins folder,
and other p2 features can be found here:

http://wiki.eclipse.org/Equinox_p2_Getting_Started

There are some known bugs in the dropins
support that we plan to have fixed for tomorrow's warm-up build. In particular,
dropins will currently fail to install if you have multiple copies of the
same singleton bundle in the folder, or any bundles that are not applicable
to the os/ws/arch of the running Eclipse configuration. The workaround
for now is to remove such bundles from the dropins folder.

The last major limitation is that you
cannot currently drop in bundles to replace bundles in the base eclipse/plugins
folder.  This is by design because it prevents users from accidentally
breaking their base application by adding additional bundles on top that
may not be compatible with the running system. However, for those of us
developing the platform itself and looking to self-host on our latest work,
it is an important feature to have. We believe the best solution for this
problem is to implement proper patch support: dropping in a different version
of a bundle in the base platform would be manifested as a patch. p2 could
then reason about the patch as a delta on top of the running system that
can be managed, upgraded, and uninstalled independently without changing
the definition of the base platform. This is a much more powerful solution
that will eventually make life easier for both ourselves as developers
of the platform, and for end users.

Unfortunately, we don't have time in
M6 to implement this patch-based solution, but it will be addressed for
M7.  The workaround in the M6 timeframe is to directly edit the eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundes.info
file to list the exact set of bundles you want to run.  Be aware that
once you do this, p2 will be broken and you will not be able to perform
further installs, uninstalls, or updates on that system with p2. This is
because from p2's point of view, you will no longer be running "version
X of the SDK", and thus cannot upgrade the SDK, or install plugins
or features that rely on the SDK being present. I.e., p2 can no longer
properly reason about what you have installed. Update Manager had this
same limitation, and we believe the patch solution above is the way to
resolve it.

Anyway, that's likely more detail on
p2 than most people care to know, but we thought it was important to let
people know the current state, and some of the reasons for it.  Bugs
can be logged against Eclipse > Equinox > p2, and further discussion
can continue on the equinox-dev mailing list or IRC channel.

Your neighbourhood p2 committers