Eclipse Ganymede：深入 PDE（Plugin Development Environment）

作为预定 6 月 25 日发布的 Eclipse Ganymede 的一部分，Infoq 将推出一系列 Eclipse 子项目的相关报道。今天，我们将探讨的子项目是插件开发环境（Plugin Development Environment——PDE）（目前正处于3.4 版）。Infoq 采访了PDE 的技术领导人及Code9 的主要顾问—— Chris Aniszczyk ，以了解更多关于 PDE 及其功用的信息。

Aniszczyk 谈到了 3.4 中几个新的特性和更新，包括：

• API 工具——API 工具提供了一个构造器（builder），可以报告工作区（workspace）中的 API 使用和二进制兼容性错误。你必须对想让 API 工具报告错误的项目进行配置，而且你必须定义一个 API 基线用以便与工作区项目进行比较。比如，针对于 Eclipse 3.4 版，当我们开发 Eclipse 3.4 时，平台团队使用 API 工具在 Eclipse 3.3.2 上定义了一个基线。API 工具能够报告兼容性错误、@since 标签缺失、不正确的版本号以及许多以前我们不得不手工检查的其它 API 问题。现在所有这些工作都在工作台（workbench）内顽完成，因此在开发的时候你就可以看到错误。比如，你给一个接口增加了一个方法但却忘记增加版本号，API 工具能帮助你又快又好地解决这个问题！查看 API 工具 wiki 可以获得更多信息。
• 打开插件制品——如果你使用 Eclipse，你极可能用过 JDT 让人敬畏的打开类型快捷方式 (Ctrl+Shift+T)。在 PDE 中我们提供了一个类似的功能。打开插件制品（Open Plug-in Artifact）（Ctrl+Shift+A）使你能够快速跳转到插件、扩展、扩展点及输出包中。你可以尝试一下，我肯定你会喜欢它！我现在每天都在用它！
• 用户援助工具——对那些喜欢在他们的 Eclipse 应用中提供用户援助的人们，如果他们听到 PDE 提供了一个新的目录编辑器和帮助上下文编辑器这个消息，一定非常高兴。你现在可以选择使用一个更好的编辑器，而不是像以前一样用手工编辑这些文件。另外，我们还为 3.4 改进了 Cheat Sheet 编辑器！
• Plug-in Spy ——当我试图在 SDK 中查找要重用的功能时，以及查找特定选定类的时候，感觉非常不便。这个功能就脱胎于此。例如，试想一下，你正在一个 RCP 项目上工作，并想在你的应用中重用 log 视图。在过去，你必须深入代码和扩展以找到 ID 和其他东西。Plug-in Spy 可以使你通过简单地选择工作台中感兴趣的插件并从中获取有用信息就可以完成这一工作。例如，在本例中，你可以选择 log 视图并调用 Plug-In Spy。你获得的是类似于如下的信息：实现该视图的实际类、这个类来自哪个插件、当前所选的类等等。
• Plug-in Registry——PDE 里的 [这个] 视图使你可以快速地看到你当前正在运行应用的状态。例如，你将看到当前活动并运行着的插件（与之相对的是不活动且没有运行的插件）。你还能很快看到并查询这些插件的可用扩展及扩展点。在 3.4 中，我们还在这个视图上增加了“Show Advanced Operations（显示高级操作）”的概念。启动、停止和诊断 bundle 都可以在视图中方便的进行。如果你需要一个能够很快看到你的基于 Eclipse 应用的状态的视图，这个视图就是为你准备的！

当被问及使用 PDE 开发除 Eclipse 插件之外的其它东西时，Aniszczyk 说道：

最近的几版中，PDE 已经提供支持开发 OSGi 独立应用。但是，我们在广告方面做得不好。它隐藏在“New Plug-in Project（新建插件项目）”向导中，但是我们允许你指定一个特定 Eclipse 版本或一个 OSGi 框架。我认为部分问题是由于我们的命名问题，不是吗？在 Eclipse 中，我们习惯使用插件（plug-in）这个词，而在 OSGi 社区中他们习惯使用 bundle 这个词。在 PDE 的特定领域内，我们试图适应这种措辞，但是目前还没有完成。例如，如果你创建一个插件（Plug-in）项目，并且指定了一个 OSGi 环境，你将注意到 OSGi 框架启动配置使用了“bundles”这个术语而不是“plug-ins”。OSGi 社区如果知道了 PDE 计划在 3.5 中为 Declarative Services 提供工具，应该会感兴趣的……在 PDE 孵化器中，我们正在开展一些令人兴奋的工作。

Aniszczyk 还进一步深入讨论了使用 PDE 开发 OSGi 应用的细节问题，说明用来指定 Eclipse 版本的相同机制也可以用来指定 OSGi 框架，除不同的 Eclipse 版本之外，PDE 也提供了独立 OSGi 应用的模板。Aniszczyk 指出通过管理 classpath 和利用已有的 Eclipse 开发套件，PDE 简化了 OSGi 开发。PDE 本身就支持 Equinox，而且也为其它 OSGi 框架如 Knopflerfish 和 Felix 提供了扩展点。Aniszczyk 还表达了与各种 OSGi 框架开发者共同工作的意愿，以把他们的成果集成到 PDE 中去，而且还说 PDE 团队一直愿意帮助那些想要做出贡献的人。

Aniszczyk 还讨论了 PDE 社区，尤其是关于他帮助启动的 BugDay 所取得的成就。针对 PDE 已经有超过100 个已贡献的BugDay bug 得到了修正，同时Aniszczyk 对PDE 团队通过 IRC 所提供的一点点帮助就能产生这么大的成果感到吃惊。Aniszczyk 还提到社区成员帮助 PDE 最好的方式就是浏览 Bugzilla 中 BugDay bug 的列表并表示有兴趣提供帮助——从那里，PDE 团队将非常乐意通过 IRC 或 Skype 提供援助，这符合 PDE 的座右铭——“我们做工具，而我们的业务就是使用工具的人”。

当被问到 PDE 如何集成到 E4 或受 E4 怎样的影响时，Aniszczyk 说道：

PDE 显然涉及到了 E4。E4 当前的焦点是帮助构建一个平台，但是众所周知，平台最终需要工具。这儿有几个当前我们正在 E4 中探索的方向： - 多语种插件——目前，所有插件都是用 Java 编写的。考虑使用其它语言如 JavaScript 以及考虑使用 Web 作为目标环境都是 E4 所关注的。我一直有个梦想——使用其它语言如 JavaScript、Groovy 或 Scala 编写 Eclipse 插件。为了使之变为现实，PDE 将要做更多的事情。要使得多语种插件成为现实，PDE 中当前还没有足够的钩子（hook）可用，而且运行时也必须支持。

• 单一源和目标平台——如果你使用 Eclipse 并开发插件，你或许熟悉目标平台的概念。在 PDE 中，目标平台简单的表示你开发所依靠的一组插件。例如，默认情况下，你所做的开发是针对正在运行的环境的。在 E4 中，可以指定不同的环境，如 Web、设备和其它什么平台。为理解我所表达的意思，可以查看一下 Eclipse EBERT样例，它示范了一个基于Eclipse 的应用，该应用可以运行在客户端、服务器端、以及嵌入式设备上，其分别使用 Eclipse 富客户端平台（Eclipse Rich Client Platform——RCP）、 Eclipse 富 Ajax 平台 （Eclipse Rich Ajax Platform——RAP）、嵌入式富客户端平台（embedded Rich Client Platform——eRCP）。开发这些类型应用的过程有点困难，因为在 PDE 中，目标平台的概念是针对每个工作区的。所以你需要把目标平台切换到你所指定平台的一组插件上。在 E4 中，PDE 将准备支持在每项目级设置目标平台，类似于你在每项目级可以指定 JRE 的方式。
• 供应（p2）——现在 Eclipse 对更新插件有了一个完全修订过的方式——p2，这里有很多机会可以创造一些奇特的工具。在 3.4 中，PDE 团队经过辛勤劳作更新了现存的关于老更新系统的工具，使其能够适应 p2。E4（甚至是 3.5）的下一步将使这些工具不仅仅适应 p2，还要与 p2 系统很好的集成，这样我们就可以做一些以前无法做到的事情。比如，想象一下，一个按一下按钮就可以进行发布的世界，而不是现在产生更新站点的方式。还可以想象一下，只需点击一个插件的右键就可以把它部署到你想要的地方……或许有一个自托管工作台……或许有一个通用的运行应用。期待着在 e4 甚至在 3.5 中能够看到 p2 工具领域的好东西出现。

最后，有许多与 E4 和 PDE 非常相关的令人兴奋的工作正在进行中。我一直认为，你可以构建真正够酷的东西，但是如果没有好的工具，采用它将是一件痛苦的事情。

查看英文原文： Eclipse Ganymede: An in-depth look at PDE (Plugin Development Environment)