了解 Eclipse 插件如何使用 OSGi
OSGi 规范定义了绑定包生命周期的基础架构和绑定包的交互方式。这些规则通过使用特殊 Java 类加载器来强制执行。在一般 Java 应用程序中，CLASSPATH 中的所有类都对所有其他类可见。相反，OSGi 类加载器基于 OSGi 规范和每个绑定包的 manifest.mf 文件中指定的选项（稍后将详细介绍）来限制类交互。
Eclipse IDE 使用围绕模块化和绑定包生命周期的一个 OSGi 子集。但是，它最低限度地使用了 OSGi 提供的服务支持。相反，Eclipse 提供自己的扩展点系统来启用绑定包交互。绑定包将功能暴露给其他扩展。绑定包还定义自己的扩展点，允许其他绑定包向其贡献功能。使用 Eclipse 中扩展点的一个示例是 Preferences 窗口。核心 Eclipse 插件提供中央窗口，并暴露扩展点以允许其他首选项页面的贡献。当插件添加到 Eclipse 中时，它们可以贡献它们自己的页面。Eclipse 中扩展点的模型不同于基本的 OSGi 服务。绑定包扩展点由定义绑定包拥有；其他绑定包只对这些点做贡献。相反，任何绑定包可以实现和使用 OSGi 服务。
回页首
使用 OSGi 实现 Eclipse
在 3.1 之前版本的 Eclipse 中，在每个插件的 plugin.xml 文件中定义插件依赖关系以及扩展和扩展点。在使用 OSGi 的新版本 Eclipse 中，依赖关系信息被分解到 manifest.mf 文件中，而 plugin.xml 文件只包含扩展和扩展点的 XML 定义。看一个演示该发展的生动的工作示例十分有用。清单 1 展示了 Eclipse V3.0 中 org.eclipse.pde.ui 插件的代码段。
清单 1. org.eclipse.pde 插件中的代码段
<?xml version="1.0" encoding="UTF-8"?><?eclipse version="3.0"?><plugin id="org.eclipse.pde.ui" name="%name" version="3.0.2" provider-name="%provider-name" name="%expoint.pluginContent.name" schema="schema/pluginContent.exsd"/> <extension-point id="newExtension" name="%expoint.newExtension.name" schema="schema/newExtension.exsd"/><extension-point id="templates" name="%expoint.templates.name" schema="schema/templates.exsd"/><extension-point id="samples" name="%expoint.samples.name" schema="schema/samples.exsd"/><!-- Extensions --> <extension point="org.eclipse.ui.perspectives"> <perspective name="%perspective.name" icon="icons/eview16/plugins.gif" encoding="UTF-8"?><?eclipse version="3.0"?><plugin> <!-- Extension points --> <extension-point id="pluginContent" name="%expoint.pluginContent.name" schema="schema/pluginContent.exsd"/> <extension-point id="newExtension" name="%expoint.newExtension.name" schema="schema/newExtension.exsd"/> <extension-point id="templates" name="%expoint.templates.name" schema="schema/templates.exsd"/> <extension-point id="samples" name="%expoint.samples.name" schema="schema/samples.exsd"/><!-- Extensions --> <extension point="org.eclipse.ui.perspectives"> <perspective name="%perspective.name" icon="icons/eview16/plugins.gif" class="org.eclipse.pde.internal.ui.PDEPerspective" id="org.eclipse.pde.ui.PDEPerspective"> </perspective>
注意，导出和导入信息不见了。该信息现在位于清单 3 所示的 manifest.mf 文件中。
清单 3. Manifest.mf
Manifest-Version: 1.0Bundle-Name: %nameBundle-SymbolicName: org.eclipse.pde.ui; singleton:=trueBundle-Version: 3.1.0Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jarBundle-Activator: org.eclipse.pde.internal.ui.PDEPluginBundle-Vendor: %provider-nameBundle-Localization: pluginRequire-Bundle: org.eclipse.core.runtime, org.eclipse.ui.ide, org.eclipse.ui.views, org.eclipse.jface.text, org.eclipse.ui.workbench.texteditor, org.eclipse.ui.editors, org.eclipse.ant.core, org.eclipse.core.resources, org.eclipse.debug.core, org.eclipse.debug.ui, org.eclipse.jdt.core, org.eclipse.jdt.debug.ui, org.eclipse.jdt.launching, org.eclipse.jdt.ui, org.eclipse.pde, org.eclipse.pde.build, org.eclipse.search, org.eclipse.team.core, org.eclipse.ui, org.eclipse.update.core, org.eclipse.ui.forms, org.eclipse.ant.ui, org.eclipse.jdt.junit, org.eclipse.ui.intro, org.eclipse.ui.cheatsheets, org.eclipse.update.configurator, org.eclipse.help.baseBundle-ManifestVersion: 2Eclipse-AutoStart: trueExport-Package: org.eclipse.pde.internal.ui;x-internal:=true, org.eclipse.pde.internal.ui.build;x-internal:=true, . . . org.eclipse.pde.ui, org.eclipse.pde.ui.internal.samples;x-internal:=true, org.eclipse.pde.ui.templates
各种插件导入现在被指定为必需的绑定包，* 包导出已经替换为显式导出的包列表。
插件级的依赖关系改为需要显式导出和导入包的依赖关系，当 Eclipse 宣布这个消息时，曾引起大量骚动。主要抱怨的是缺乏已经存在于 Eclipse 早期版本中的 <export name="*"/> 的替代物。但是，该省略有许多原因。最重要的原因是从显式导入和导出中获得的速度收益。早期版本的 Eclipse 必须打开并浏览每个插件 jar 文件以确定它包含哪些类。不包括 * 导出还提供了一级保护来避免插件暴露不必要的类。插件开发人员必须进行专门选择来使插件中的功能可供外部使用。该限制允许内部包保留在内部。
回页首
OSGi 清单选项
OSGi R4 框架核心目前的规范草案几乎有 PDF 格式的 300 页。介绍该规范的每个部分超出了本文范围，但我将讨论 Eclipse 插件开发人员特别感兴趣的 OSGi manifest.mf 选项：
Bundle-Activator该类用于启动和停止绑定包。在上面的示例插件中，指定了 org.eclipse.pde.internal.ui.PDEPlugin 类。该类扩展 org.eclipse.core.runtime.Plugin，实现了 BundleActivator 接口。Bundle-ClassPath该属性指定要用于绑定包的 CLASSPATH。该属性可以包含对绑定包 jar 文件中目录或 jar 文件的引用。可以使用句点指明绑定包的根。在示例 Eclipse PDE 绑定包中，指定了绑定包 jar 文件中的 org.eclipse.pde.ui_3.1.0.jar。如果将插件的源版本导入工作区中，导入过程将更改绑定包 CLASSPATH 以显示为 Bundle-ClassPath:，这允许插件的开发版本挑选已编译的绑定包类。Bundle-Version该属性指定绑定包的版本号。包导入和必需的绑定包规范可以包括绑定包版本号。Export-Package该属性指定要公共暴露给其他插件的所有包。Import-Package该属性指定要从必需插件中显式导入的所有包。默认情况下，必须为要启动的绑定包解析所有包。还可以将包导入指定为可选项，以支持包不存在的情况。显式导入的类在 Require-Bundle 插件中的包之前解析。Require-Bundle该属性指定要在给定绑定包中导入使用的绑定包及其已导出的包。指定的绑定包在显式包导入之后解析。Eclipse 提供的其他清单选项
伙伴类加载器选项首先为 Hibernate 创建插件。然后创建一个插件，其中包含与 Hibernate 有依赖关系的特定于域的类。将下列行添加到 Hibernate 插件清单中：Eclipse-BuddyPolicy: registered。
将下列清单属性添加到包含特定于域的类或资源的插件清单中： Eclipse-RegisterBuddy: hibernate。
该行允许插件通过声明将自己暴露给 Hibernate 插件，而它预先并不知道这些插件。现在，Hibernate 插件可以看到需要的类，虽然它并没有专门导入它们。
OSGi 规范包括的 manifest.mf 配置选项不提供 Eclipse 平台需要的所有功能。因此，Eclipse 创建者添加了多个扩展（还建议将它们包括在未来版本的 OSGi 规范中）：
Export-Package 头扩展Eclipse 具有两个 OSGi 解析器方法 —— default 和 strict，可以使用 osgi.resolver 属性指定它们。Eclipse 还包括对 Export-Package 属性的两个扩展 —— x-internal 和 x-friends，启用 Strict 模式时，会强制执行这两个扩展。x-internal该属性的默认值是 false。当使用该选项将内部包指定为 true 时，Eclipse PDE 禁止其使用。x-friends该选项类似于 x-internal，但允许特定绑定包使用具有该选项的已导出包。其他绑定包被禁止。x-internal 选项优先于 x-friends。Eclipse-AutoStart默认情况下，Eclipse 根据需要加载绑定包。因此，当导入绑定包包含的第一个类的绑定包需要这个类时，就会加载这些绑定包。将该值指定为 ?? 会导致 Eclipse 在启动时加载绑定包。还可以指定例外情况列表，它们是无需启动包含它们的绑定包就可以加载的类和资源。Eclipse-PlatformFilter该属性允许为要启动的绑定包指定必须等于 true 的条件。可以将下列信息包括在指定的表达式中：osgi.nl，表示语言osgi.os，表示操作系统osgi.arch，表示架构osgi.ws，表示窗口系统展示如何使用该属性的一个示例是，在启动使用 SWT_AWT 桥的插件之前验证操作系统是否是 Mac OS X。（Standard Widget Toolkit（SWT）的 Mac OS X 实现当前不支持该功能。）Eclipse-BuddyPolicy该选项指定加载绑定包策略的类。通常，绑定包只在其内部类和从依赖绑定包中导入的内部类中具有可见性。在 Eclipse 新闻组中用来解释伙伴类加载的流行示例是 Hibernate。Hibernate 框架必须查看用户创建的而非 Hibernate 本身一部分的类和资源。这样的一种情况是当使用项目动态填充来自 Hibernate Query Language（HQL）查询的类时。默认情况下，Hibernate 将无法查看位于包含 Hibernate jar 文件的插件外部的类，而需要修改 Hibernate 插件以创建包含 Hibernate 地图不可接受的类的每个插件。幸运的是，伙伴类加载器选项 一节中介绍的伙伴类加载器选项解决了这个问题。回页首
Eclipse 和 OSGi 的未来趋势
Eclipse 已经从使用 OSGi 中大大受益，获得了以动态方式管理组件生命周期的一个健壮的系统。新的使用方法每天都在被发掘，比如服务器层特征 servlet、JavaServer Pages 以及 Eclipse 样式插件中的其他 HTTP 资源。
Eclipse Foundation 已经决定在驱动 OSGi 规范向前发展的过程中扮演关键角色，以便于自己和其他人利用 OSGi。在从专用 Eclipse 插件框架转换到 OSGi 的过程中，对 OSGi 规范进行了许多添加，这些添加成了 OSGi R4 规范发行版的一部分。因此，Eclipse Equinox 项目已经成为不断发展的 OSGi 参考实现。该实现以及用于管理发展 OSGi 的 Java Specification Request（JSR） 291 的创建，保证了 Eclipse/OSGi 合作伙伴关系将在未来几年里不断取得成功。