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 能及时修正并保持稳定吗？

查看英文原文： Is P2 ready for Eclipse?