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?
评论