Eclipse Ganymede：深入 Equinox p2（供应平台）

P id=rf-f5> 作为预定 6 月 25 日发布的 Eclipse Ganymede 的一部分，Infoq 将推出一系列 Eclipse 子项目的相关报道。今天，我们将探讨的子项目是 Equinox p2 （供应平台），它是供应基于 Eclipse 应用的框架。Infoq 采访了 Jeff McAffer 和 Pascal Rapicault 以了解更多关于 p2 及其功用的信息。

在谈到 p2 给 Eclipse 带来的实际功能时，Rapicault 表示 p2 的 1.0 版其实是为替代已有的更新管理器（Update Manager——UM）而设计的。McAffer 反复重申了以下几个特性：

1. 在所有可用资源范围内自动重试下载
2. 自动选择最佳镜像
3. Bundle 共享允许在多个 eclipse 实例范围内共享插件
4. 管理完整安装（exe、ini、etc）的能力
5. 无需运行即可管理和更新 Eclipse 实例的能力
6. 易于创建无界面（headless）和定制更新用户界面
7. 校验插件间依赖。因此只需安装协同工作的插件，而且一旦安装就能运行
8. 多线程下载加快下载速度
9. 只安装所需插件，减少安装的插件总数
10. 创建知道如何从多个资源获得插件的强力更新（uber-update）站点
11. p2 意味着无需重新安装 Eclipse，只需更新即可
12. 一个可以作为常规 Java 应用或使用 Java Web Start 来运行的安装程序。它可用来安装和配置 Eclipse 的所有内容。
13. 更干净的终端用户工作流程

当被问到 p2 的诞生是为了解决 UM 存在的哪些问题时，McAffer 说上面列出的这些特性其实非常紧密地结合了 UM 所存在的问题。Rapicault 指出 UM 无法随着 Eclipse 平台的进化而发展，使得很少开发团队选择使用 UM。设计 P2 的其中一个目标就是为了同时吸引终端用户和平台开发者，Rapicault 这样说道：

我们必须使那些从未真正购买 UM 的人们相信我们能够给他们提供实际的帮助，这是一个巨大的挑战。由于他们已经习惯我们目前提供的操作方式，再让这群习惯了使用 UM 来应付各种工作流程的人们做出改变非常困难。

P2 还给 Eclipse 带来了新的在线安装的能力，只需一个简单的小安装器和可定制的 Java Web Start 安装程序即可。该安装程序将被集成到一个新的由 clipse Packaging 项目所创建的基于 Web 的安装向导中。McAffer 还提到这些安装程序只是 p2 为基于 Eclipse 和基于 OSGi 系统提供的供应功能的“冰山一角”。Rapicault 补充说，那些希望扩展 p2 的人会惊喜地发现 p2 拥有一个模块化的、成套的功能“积木”，无论这个应用是运行在桌面、服务器还是手机上，都可以用来管理基于 OSGi 的应用。McAffer 指出 p2 不是 Eclipse 特有技术，它可以在 Web 应用中运行、可以在无显示环境中（headless environments）运行、可以是像 Eclipse IDE 这样一个大应用的一部分、也可以作为独立个体单独运行。McAffer 还补充说：“无论是 p2 的设计理念还是最终实现，都使得 p2 可以为任何类型的应用提供支持”。

McAffer 还详细描述了如何在 Web 应用中运行 p2 的过程：

p2 可以被打包在 Web 应用中。你也知道，Equinox 这个支撑 Eclipse 的 OSGi 实现如今在服务器上使用得相当广泛。某些情况下，它可以作为应用服务器和其他应用的实现，程序员能够清楚地看到 OSGi 模型和 Equinox 功能。Equinox servlet bridge 的使用可以帮助开发员在一个 WAR 中获得 Equinox 和 OSGi 的所有功能和灵活性。例如，你可以部署一个简单的标准 WAR，在这个 WAR 中只包含 Equinox 和 p2，然后用 p2 供应技术去配置和运行真正的 Web 应用，最后得到的这些应用可以被动态扩展和更新。

在 p2 的开发过程中，开发团队曾面临过几个大的挑战。InfoQ 分别向 McAffer 和 Rapicault 了解了他们当时遇到的一些挑战以及最终选择的解决方案，McAffer 这样回答：

这个问题问得很好。我们的团队是幸运的，我们从 UM 和其他供应解决方案中学到很多东西。我举几个例子来说明当时遇到的一些挑战以及对应的解决方案。元数据（Metadata）——直接或间接的元数据结构和格式耗费了我们好几个月的时间。许多人问的第一个问题是“你们的元数据格式（即 XML）是什么？”或者“我能看一下大纲吗（schema）？”。我们的回答基本上（分别）是“我们没有指定”或“不行”。规定格式的问题在于你是在假定你定义的格式它恰恰就是那个能够在任何情况下都适用的格式。可现如今，这根本不可能。有许多老的更新站点、OSGi Bundle 库、Maven 库……终端用户需要连接所有这些库或者更多其它的站点。我们最终的答案是在 API 级指定元数据，把格式细节的定义留给提供仓库的人。开发人员只需实现几个简单的接口，就能提供一个仓库。当然，我们也提供了一个拥有 p2 所有特性的仓库实现。p2 与传统更新站点和其它捐献的仓库实现都配合得非常好。

仓库（Repositories）——我们认为仓库灵活性是使用和采纳 p2 的关键。许多人都有现存的存储、格式或系统，而 p2 不会去取代这些已有的东西。此处的关键是分离元数据和制品结构。事实证明，只有在新建数据存储或重用已有数据存储方面赋予 p2 绝对的灵活性，p2 才能取得成功。我们还打算在 p2 中逐渐渗透仓库的概念。当你安装 bundle 时，这些 bundle 实际上会进入仓库，轮流供应其他配置或其他系统。组成系统的组件的配置也是一个仓库。为了实现刚刚提到的这些操作，我们使用了处处镜像（mirroring everywhere）的概念。实际上，大部分时候你都不是真正地从存储源下载，而是从其他人的镜像下载，同时你下载的东西也为别人提供了镜像。我们还抽象出来了制品格式的概念，这样一个制品仓库可以存储同一个制品的多种形式。例如，标准的 JAR 文件和一个使用 Pack200 打包的 JAR 文件，这两个制品版本的二进制比较是有差异的……尽管存有差异却能共存于同一仓库。在供应一个给定系统时，p2 会选择最有效的形式。

约束解析（Constraint resolution）——在基于 OSGi 的系统中表达基本依赖集相对比较简单，然而还是有许多其它约束需要定义，而供应真正的企业系统则截然不同。我们选择了通常使用的“请求和供给”形式来约束系统，但最酷的部分还是伪布尔约束引擎（pseudo-boolean constraint engine）——SAT4J，我们用它选择组件来构建系统。其实一般的约束都会被影射成为一些伪布尔等式及表达预期结果的权重集合。SAT4J 以这个权重集合为输入，返回一个解决方案。这个方案会被影射回组件以告诉 p2 要安装什么、卸载什么或更新什么。所有这些又简单又快速。更好的是方案可以通过适当使用不同的函数进行优化。比如你可以编写一个空间优化（安装最小配置）函数或改动最小的函数……有一些活跃的研究团队正在关注这类东西，而 p2 已经开始使用这些结果。

灵活的架构（Flexible architecture）Eclipse 的应用范围很广，从嵌入式系统到富客户端应用、再到工具、服务器端。这就对供应基础架构的灵活配置提出了更多要求。可插拔仓库、不同的供应策略、多路传输、多个机器上的供应逻辑定位、远程管理……为了实现这些功能，我们在设计和实现上都采用了高模块化的方法。大多数更新管理用户应该都很熟悉 Ganymede 里的 P2 结构，这个结构在“平凡的外表”之下有着非比寻常的灵活性。

Rapicault 接着补充道：

对我来说，更新管理兼容性以及共存（cohabitation story）方面（UM/p2 处于同一个系统，这是 SDK 默认的）可能是最大的挑战之一。UM 在它业已７年的生涯中提供了很多方法来管理系统，其中不乏一些方式从 p2 的角度来看会显得非常怪异。为此，我们针对错误、代码和其它我们所能找到的相关文档进行了研究，以确保不遗漏任何用例。这样，我们成功地在一年内完全替换了这个已经使用了 7 年的老产品。 另一个挑战是跳出“原型”或“让我们构建一个真正灵活的超级平台”这样的思维定势，把注意力集中在到 ppl 可用的一些东西上。为此我们经常问自己，“这是 UM 中的东西吗”？这样经常性地自问自答保证了我们在开发的过程中没有偏离“正道”。

从纯粹的内在复杂性来讲，解析器也极具挑战。经过几个月的研究和原型搭建，我们发现了两篇研究论文不异而同地谈到了 SAT 求解程序在类似情况下的使用。当时立马就觉得这就是我们一直在寻找的解决方案，于是我开始使用 SAT4J 创建原型。一旦 PMC 确信放置一个求解程序来处理 eclipse 的 NP 完整性问题是正确的方向，我们就开始动手了。我们也庆幸以 Daniel Le Berre 和 Anne Parrain 为代表的 SAT4J 团队，带给我们许多信息并给我们提供了大量的帮助。在这次开发中，我们建立了真诚的双边协作关系。现在再回想之前种种，我真的很高兴当时我们做出了这样的选择。我们计划借助更多的求解程序能力来改进未来版本中成套插件和产品的工作方式。

从头建立一个社区也是一个挑战。在某种意义上，它对我们来说是新生事物，我们必须从项目诞生之日起就要与社区一起工作。我们很幸运可以在供应研讨会上见到许多未来的贡献者，而且后来在聚集了这一领域专家 / 志士的 equinox 峰会上，我们也得以和大家分享我们的愿景。付出总会有回报，目前已经有一个公司在 p2 的基于上开发了一个商业产品；还有另一家公司正在针对他们的商业产品编写基于 p2 的安装程序，该产品除了基于 Eclipse 的应用外还包括其他组成部分。

至于 p2 的未来计划，McAffer 指出 1.0 版的目的是建立一个基础架构，在这个基础构架上将来还会有更多的开发。工具、供应策略、性能提升以及扩展至更多运行时系统，这些都在 p2 的功能列表中，p2 的应用范围将非常广泛。Rapicault 补充说，随着社区及供应行为的不断成长，p2 与桌面的集成也被纳入计划。McAffer 还说，就像 Eclipse 团队不会为 Eclipse IDE 能够支持的所有语言提供支持一样，p2 团队也将给来自社区的其它团队留出空间，使其能够在 p2 的基础开发出定制的解决方案。

当问到 p2 将如何集成到 e4 中，以及 p2 有没有受到 e4 的影响时，McAffer 说：

从一开始我就把 p2 看作是 e4 的成果。只是由于偶然，它的出现比预计要来得更早一些，刚好可以被 Eclipse 3.x 采用，但我们的设计也考虑到了包括类似 e4 的一些场景。E4 被定位为更动态、更具模块化及更加松耦和。这些特性在彰显众多机会的同时也带来了巨大的挑战。我们希望 p2 能够尽可能贴近终端用户和系统集成者，也给人们带来管理 e4 的高集成系统的能力。p2 将会是 e4 的主要组成部分。

查看英文原文： Eclipse Ganymede: An in-depth look at Equinox p2 (Provisioning Platform)