P2为Eclipse准备好了吗？

Eclipse更新管理器可以从一个或者多个远程站点更新安装的Eclipse。到目前为止，它已经成为更新发布（如从3.3.0到3.3.1）和安装新特性最常用的方式。然而，它也存在不少问题，如无法更新可执行的eclipse及处理镜像失败。

为了解决这些问题，在EclipseCon 2007的一个BoF会上，介绍了新一代的更新机制。随后Provisioning Platform（简称为P2）诞生了。从那以后，它就从孵化器中走出来了，并在3.4M5首次登场。

不像以前的Eclipse更新管理器，P2既可以更新包（bundles），也可以更新其他东西（non-bundles）。这为使用P2来更新DLLs和构成应用的其他可执行程序的系统（如Wascana，这是一个基于MinGW的CDT包，使得我们可以在Windows上进行GUN开发）敞开了大门。

P2澄清了可安装单元（就是关于能被安装的东西的元数据，而不是将要被安装的东西；想一下Maven的pom.xml）和将要被安装的制品（包、可执行文件、库还是其他的东西）的概念。另外，这些东西被存储在单独的位置以便更新系统能迅速决定要安装（是否能满足依赖关系）什么东西，而不必将这些制品下载下来。

下载由Eclipse通信框架（Eclipse Communication Framework）负责。制品还可以通过几种不同的算法（pack200、tar.gz）进行压缩，同时对于多线程下载来说，还有多个镜像可用。在下载过程中，如果更新站点出现问题时，以前的更新管理器就会失败，而P2会自动地重试不同的镜像以便找到数据。你甚至可以下载一个只有5Mb的安装器，它会安装Eclipse及其所有插件。

很显然P2解决了很多旧的Eclipse更新管理器所无法克服的问题，同时也收到了很多积极的评论。然而，对于底层的基础设施来说依然有大量工作需要完成，直到最近才开始开发UI，这也有很多工作要做。此外，尽管3.4M7计划与更新管理器保持向后兼容，P2现在已经胜出了旧的更新管理器，可是很显然，这两者现在都不太完善。

缺失的主要特性之一就是安装到不同扩展位置的能力。很多人使用它来安装功能的不同子集，尤其是在Eclipse的多套安装中安装一套共享的插件集（像Subversive或是Subclipse）时更是如此，正如IBM开发者网站上的文章所述。这使得有些人希望继续使用更新管理器，而且目前还对P2产生了一些负面印象，更不要说安装器还不支持Mac OS X了。

很明显P2是未来之路；相对于更新管理器，它有太多的优点了。但是它仍然需要测试，随着上周3.4RC1的发布，离下个月Ganymede的发布时间已经越来越近了。你认为P2能及时修正并保持稳定吗？

【相关文章】