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

http://www.infoq.com/cn/news/2008/06/eclipse-ganymede-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的主要组成部分。