了解 Eclipse 插件如何使用 OSGi

Eclipse 和 OSGi 的关系，从 plugin.xml 到 manifest.mf


级别： 中级
Scott Delap (scott@clientjava.com), Desktop/Enterprise Java 顾问
2006 年 9 月 21 日
Eclipse 集成开发环境（IDE）和 Eclipse Rich Client Platform（RCP）应用程序的核心由 Open Services Gateway Initiative（OSGi）规范的实现驱动。本文通过描述对 Eclipse 平台而言插件是什么，并跟踪从 Eclipse V2.1 到今天基于 OSGi 的实现中插件的发展，阐明了 Eclipse 与 OSGi 的关系。还解释了 OSGi manifest.mf 文件选项以及通过 Eclipse 提供的添加项。
大多数 Java™ 编程语言开发人员通过作为 IDE 的功能认识了 Eclipse。Eclipse IDE 实际上由叫做插件 的交互式组件的集合组成。这些插件组成了 IDE 的基础，它们还可用于创建其他桌面应用程序。创建基于 Eclipse 的应用程序所需的最小插件集称为 Eclipse Rich Client Platform（RCP）。但是，插件本身不能启动。它们需要在一个环境中启动和操作。Eclipse 使用 OSGi R4 规范的实现提供了该环境。
因为 Eclipse 在本质上是由 OSGi 驱动的，因此必须了解 Eclipse 插件的概念与 OSGi 框架有什么关系。在本文中，我将通过描述对 Eclipse 平台而言插件是什么来详细解释这种关系。然后，将描述在 Eclipse V2.1 平台到今天基于 OSGi 的实现中插件的发展。最后，将详细介绍应用于 Eclipse 插件的 OSGi 提供的 manifest.mf 选项。
Eclipse 联机帮助将插件定义为：
“插件是为系统提供功能的代码和/或数据的结构化包。可以以代码库（带有公共 [应用程序接口] API 的 Java 类）、平台扩展甚至文档的形式来提供功能。插件可以定义扩展点、定义良好的位置，其他插件可以在这些位置添加功能。”
要注意的一个重点是插件以结构化方式提供功能。它们可以提供服务（比如日志）或可用于用户界面（UI）的功能，比如编辑器。不管什么功能，所有插件都以相同的结构化方式来定义。


如前所述，Eclipse 使用 OSGi 作为插件系统的基础。但并非总是如此。早期版本的 Eclipse 也设计为插件集合，而且 Eclipse 包括自己专用的插件系统来管理交互。但是，随着 Eclipse IDE 要求的增长，必须需要一个更强壮的解决方案。这个新系统的基本要求包括动态添加新插件和停止现有插件的能力。经过大量研究之后，Eclipse 创建者决定通过实现 OSGi 框架规范替换专用的插件框架。
OSGi 是服务平台的规范。Eclipse 提供了该规范的许多可用实现之一，并用作最新 OSGi R4 规范的参考实现。OSGi 是基于 Java 的框架，旨在用于需要长运行时间、动态更新和对运行环境破坏最小的系统。起初，OSGi 旨在用于家庭自动化和家庭网关设备。最近，从手机到汽车都发现了它的踪迹。
在核心，OSGi 是一个组件和服务模型，如图 1 所示。OSGi 规范定义了一个叫做绑定包 的模块化单位。（在下文中，除非特别指明，Eclipse 术语插件 和 OSGi 术语绑定包 可交换使用，因为所有 Eclipse 插件现在都是 OSGi 绑定包。）OSGi 还提供了 Java Virtual Machine（JVM）级别的服务注册，该绑定包可用于发布、发现和绑定至服务。

OSGi 规范定义了绑定包生命周期的基础架构和绑定包的交互方式。这些规则通过使用特殊 Java 类加载器来强制执行。在一般 Java 应用程序中，CLASSPATH 中的所有类都对所有其他类可见。相反，OSGi 类加载器基于 OSGi 规范和每个绑定包的 manifest.mf 文件中指定的选项（稍后将详细介绍）来限制类交互。
Eclipse IDE 使用围绕模块化和绑定包生命周期的一个 OSGi 子集【Eclipse用到了一个OSGI的子集，这个子集的核心是1.模块化2.绑定申明周期】。但是，它最低限度地使用了 OSGi 提供的服务支持。相反，Eclipse 提供自己的扩展点系统来启用绑定包交互。绑定包将功能暴露给其他扩展。绑定包还定义自己的扩展点，允许其他绑定包向其贡献功能。使用 Eclipse 中扩展点的一个示例是 Preferences 窗口。核心 Eclipse 插件提供中央窗口，并暴露扩展点以允许其他首选项页面的贡献。当插件添加到 Eclipse 中时，它们可以贡献它们自己的页面。Eclipse 中扩展点的模型不同于基本的 OSGi 服务。绑定包扩展点由定义绑定包拥有；其他绑定包只对这些点做贡献。相反，任何绑定包可以实现和使用 OSGi 服务。


在 3.1 之前版本的 Eclipse 中，在每个插件的 plugin.xml 文件中定义插件依赖关系以及扩展和扩展点。在使用 OSGi 的新版本 Eclipse 中，依赖关系信息被分解到 manifest.mf 文件中，而 plugin.xml 文件只包含扩展和扩展点的 XML 定义。看一个演示该发展的生动的工作示例十分有用。清单 1 展示了 Eclipse V3.0 中 org.eclipse.pde.ui 插件的代码段。

声明暴露了插件中的所有包以供其他插件使用。插件依赖关系导入部分列出了 org.eclipse.pde.ui 插件需要的必备插件。
接下来两部分定义了 org.eclipse.pde.ui 可用于其他插件的扩展点以及它对其他插件的贡献。在本例中，可以看到自定义 Eclipse Plug-in Development Environment（PDE）视图的定义。
下面来看 Eclipse V3.1 中的同一插件定义。清单 2 展示了 plugin.xml 文件。

注意，导出和导入信息不见了。该信息现在位于清单 3 所示的 manifest.mf 文件中。
Manifest-Version: 1.0 Bundle-Name: %name Bundle-SymbolicName: org.eclipse.pde.ui; singleton:=true Bundle-Version: 3.1.0 Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jar Bundle-Activator: org.eclipse.pde.internal.ui.PDEPlugin Bundle-Vendor: %provider-name Bundle-Localization: plugin Require-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.base Bundle-ManifestVersion: 2 Eclipse-AutoStart: true Export-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 早期版本中的 的替代物。但是，该省略有许多原因。最重要的原因是从显式导入和导出中获得的速度收益。早期版本的 Eclipse 必须打开并浏览每个插件 jar 文件以确定它包含哪些类。不包括 * 导出还提供了一级保护来避免插件暴露不必要的类。插件开发人员必须进行专门选择来使插件中的功能可供外部使用。该限制允许内部包保留在内部。


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 该属性指定要在给定绑定包中导入使用的绑定包及其已导出的包。指定的绑定包在显式包导入之后解析。

首先为 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 中大大受益，获得了以动态方式管理组件生命周期的一个健壮的系统。新的使用方法每天都在被发掘，比如服务器层特征 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 合作伙伴关系将在未来几年里不断取得成功。
学习
您可以参阅本文在 developerWorks 全球站点上的英文原文 。
有关 Eclipse 和 OSGi 的简介，请阅读 “利用 OSGi 解决 Eclipse 插件难题”。
有关 OSGi 的更多信息，请访问OSGi Alliance。
Wikipedia 提供OSGi 的良好定义。
研究Oscar，一个备选 OSGi 实现。
Knopflerfish 是另一个备选 OSGi 实现。
了解有关Equinox 项目的更多信息。
“EclipseCon 2006, OSGi on the Rise” 描述了 2006 年 3 月的 EclipseCon 会议，在此次会议上 OSGi 是一个主要议题。
“Eclipse goes Server-side!”（作者 Wolfgang Gehner）解释了如何创建可以部署到 servlet 容器的 Eclipse 插件。
阅读 JSR 291 规范JSR 291: Dynamic Component Support for Java SE。
访问 IBM developerWorksEclipse 项目资源，扩展您的 Eclipse 技术。
浏览 developerWorks 上所有的Eclipse 内容。
请访问developerWorks 开放源码专区，获得丰富的 how-to 信息、工具和项目更新，帮助您用开放源码技术进行开发，并与 IBM 产品结合使用。
随时关注developerWorks 技术活动和网络广播。
获得产品和技术
请用IBM 试用软件 改进您的下一个开放源码开发项目，这些软件可以下载或从 DVD 获得。
讨论
参与developerWorks blogs，加入 developerWorks 社区。



Scott Delap 是专注于 Java EE 和富 Java 客户机的独立顾问。他在 JavaOne 撰写文章并积极活跃于桌面 Java 社区。他还是 ClientJava.com 的管理员，该网站是专攻桌面 Java 开发的门户网站。ClientJava.com 频繁出现于 Web 上，从 JavaBlogs 一直到 Sun Microsystems 的网站。
Understanding how Eclipse plug-ins work with OSGi
Eclipse and OSGi from A to Z, or in this case, plugin.xml to manifest.mf

Document options

Print this page

E-mail this page
Rate this page

Help us improve this content
Level: Intermediate
Scott Delap (scott@clientjava.com), Desktop/Enterprise Java Consultant
06 Jun 2006
The core of the Eclipse integrated development environment (IDE) and Eclipse Rich Client Platform (RCP) applications is driven by an implementation of the Open Services Gateway Initiative (OSGi) specification. This article illustrates Eclipse's relationship with OSGi by describing what a plug-in is in terms of the Eclipse platform and traces the evolution of plug-ins from Eclipse V2.1 through today's OSGi-based implementation. It also explains the OSGi manifest.mf file options, along with the additions provided through Eclipse.
Most Java™ programming language developers are introduced to Eclipse through its function as an IDE. The Eclipse IDE actually consists of a collection of interacting components called plug-ins. These plug-ins, which make up the base of the IDE, can also be used to create other desktop applications. The minimal set of plug-ins needed to create an Eclipse-based application is referred to as the Eclipse Rich Client Platform (RCP). Plug-ins don't just start themselves, however. They require an environment in which to start and operate. Eclipse provides this environment with an implementation of the OSGi R4 specification.
Because Eclipse is at its core driven by OSGi, it's important to understand how the concept of an Eclipse plug-in relates to the OSGi framework. In this article, I will explain this relationship in detail by describing what a plug-in is in terms of the Eclipse platform. Then I'll describe the evolution of plug-ins in the Eclipse V2.1 platform through today's OSGi-based implementation. Finally, the OSGi-provided manifest.mf options that apply to Eclipse plug-ins will be covered in detail.
The Eclipse online help defines a plug-in as follows:
"Plug-ins are structured bundles of code and/or data that contribute function to the system. Function can be contributed in the form of code libraries (Java classes with public [application program interfaces] APIs), platform extensions, or even documentation. Plug-ins can define extension points, well-defined places where other plug-ins can add functionality."
The key point to focus on is that plug-ins contribute function in a structured manner. They may provide a service such as logging or piece functionality available in the user interface (UI), such as an editor. Regardless of their function, all plug-ins are defined in the same structured way.


Back to top
As mentioned, Eclipse uses OSGi as the basis for its plug-in system. This wasn't always the case, however. Early versions of Eclipse were also designed as a collection of plug-ins, and Eclipse included its own propriety plug-in system to manage the interaction. However, as the requirements of the Eclipse IDE grew, it became apparent that a more robust solution was required. Basic requirements of this new system included the ability to dynamically handle the addition of new plug-ins and stopping existing plug-ins. After considerable research, the Eclipse creators decided to replace the proprietary plug-in framework by implementing the OSGi framework specification.
OSGi is a specification of a service platform. Eclipse provides one of many available implementations of this specification and serves as the reference implementation of the latest OSGi R4 specification. OSGi is a Java-based framework targeted for use by systems that require long running times, dynamic updates, and minimal disruptions to the running environment. Initially, OSGi was targeted at home automation and residential gateway devices. More recently, it has found use in everything from mobile phones to cars.
At its core, OSGi is a component and service model, as illustrated in Figure 1. The OSGi specification defines a unit of modularization called a bundle. (Unless explicitly noted during the rest of this article, the Eclipse term plug-in and the OSGi term bundle are used interchangeably because all Eclipse plug-ins are now OSGi bundles.) OSGi also provides a Java Virtual Machine (JVM)-level service registry that bundles can use to publish, discover, and bind to services.

The OSGi specification defines an infrastructure 【基础结构，基础设施】for a bundle's life cycle and how bundles interact. These rules are enforced through the use of special Java class loaders. In an average Java application, all classes in the CLASSPATH are visible to all other classes. In contrast, the OSGi class loaders restrict class interaction among bundles based on the OSGi specification and the options specified (covered in detail later in this article) in the manifest.mf file for each bundle.
【OSGI中Bundle的相互作用跟Average java Application之间的区别，前者类与类之间发生作用，需要指定ClassPath，后者则通过Manifest来指定bundle之间怎么作用】
The Eclipse IDE uses a subset of OSGi centered around modularization and bundle life cycle. However, it makes minimal use of the service support OSGi provides. Instead, Eclipse provides its own extension point system to enable bundle interaction. Bundles expose functionality as contributions to other extensions. Bundles also define their own extension points, to which other bundles may contribute. An example of using extension points in Eclipse is the Preferences window. A core Eclipse plug-in provides the central window and exposes an extension point to allow the contribution of additional preference pages. As new plug-ins are added to Eclipse, they can contribute their own pages. The model of extension points in Eclipse is different from basic OSGi services. Bundle extension points are owned by the defining bundle; other bundles simply contribute to them. In comparison, any bundle can implement and use an OSGi service.


Back to top
In versions of Eclipse before 3.1, you defined plug-in dependencies, as well as extensions and extension points, in each plug-in's plugin.xml file. In the newer versions of Eclipse that use OSGi, dependency information has been broken out into the manifest.mf file, leaving the plugin.xml file containing only XML definitions of extensions and extension points. It is useful to look at a live, working example of this evolution. Listing 1 shows an excerpt from the org.eclipse.pde.ui plug-in from Eclipse V3.0.

The declaration exposes all packages in the plug-in for use in other plug-ins. The plug-in dependency imports section lists the prerequisite plug-ins the org.eclipse.pde.ui plug-in requires.
The next two sections define the extension points org.eclipse.pde.ui makes available to other plug-ins, as well as the contributions it makes to them. In this case, you can see the definition of a custom Eclipse Plug-in Development Environment (PDE) perspective.
Let's look at the same plug-in definition in Eclipse V3.1. Listing 2 shows the plugin.xml file.

Notice that the export and import information is gone. This information now resides in the manifest.mf file shown in Listing 3.
Manifest-Version: 1.0 Bundle-Name: %name Bundle-SymbolicName: org.eclipse.pde.ui; singleton:=true Bundle-Version: 3.1.0 Bundle-ClassPath: org.eclipse.pde.ui_3.1.0.jar Bundle-Activator: org.eclipse.pde.internal.ui.PDEPlugin Bundle-Vendor: %provider-name Bundle-Localization: plugin Require-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.base Bundle-ManifestVersion: 2 Eclipse-AutoStart: true Export-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
The various plug-in imports are now specified as required bundles, and the * package export has been replaced with a list of explicitly exported packages.
The move away from plug-in-level dependencies to dependencies that required the explicit exporting and importing of packages generated a lot of commotion when Eclipse announced the news. The primary complaint was the lack of an equivalent of , which had existed in earlier versions of Eclipse. There are many reasons for this omission, however. The most important reason is the speed gains from having explicit import and exports. Previous versions of Eclipse had to open and scan each plug-in jar file to determine which classes it contained. Not including a * export also provides a level of protection against plug-ins exposing unwanted classes. Plug-in developers must make a conscious choice to make functionality in a plug-in available for outside use. This restriction allows internal packages to stay internal.


Back to top
The current draft specification for the OSGi R4 framework core is almost 300 pages in PDF form. Covering every portion of this specification is outside the scope of this article, but I do discuss the OSGi manifest.mf options of particular interest to Eclipse plug-in developers:
Bundle-Activator This class is used to start and stop the bundle. In the example plug-in above, the org.eclipse.pde.internal.ui.PDEPlugin class is specified. This class extends org.eclipse.core.runtime.Plugin, which implements the BundleActivator interface.
Bundle-ClassPath This property specifies the CLASSPATH to use for the bundle. The property may contain references to directories or jar files inside the bundle jar file. You can use the period to indicate the bundle's root. In the case of the example Eclipse PDE bundle, org.eclipse.pde.ui_3.1.0.jar in the bundle jar file is specified. If you import the source version of the plug-in into your workspace, the import process changes the bundle CLASSPATH to appear as Bundle-ClassPath:, which allows the development version of the plug-in to pick up the compiled bundle classes.
Bundle-Version This property specifies the version number of the bundle. Package imports and required bundle specifications may include a bundle version number.
Export-Package This property specifies all the packages to publicly expose to other plug-ins.
Import-Package This property specifies all the packages to explicitly import from required plug-ins. By default, all packages must be resolved for a bundle to start. You can also specify package imports as optional to support cases in which a package may not exist. Explicitly imported classes are resolved before packages from Require-Bundle plug-ins.
Require-Bundle This property specifies which bundles and their exported packages to import for use in the given bundle. Specified bundles are evaluated after explicit package imports.

Begin by creating a plug-in for Hibernate. Then create a plug-in containing the domain-specific classes with a dependency on Hibernate. Add the following line to the Hibernate plug-in manifest: Eclipse-BuddyPolicy: registered.
Add the following manifest property to the manifest of the plug-in containing the domain-specific classes or resources: Eclipse-RegisterBuddy: hibernate.
This line allows plug-ins to declaratively expose themselves to the Hibernate plug-in without it knowing about them beforehand. Now the Hibernate plug-in can see the needed classes even though it did not specifically import them.
The manifest.mf configuration options that the OSGi specification includes don't provide all the functionality that the Eclipse platform requires. As a result, the Eclipse creators have added several extensions (and also proposed them for inclusion in future versions of the OSGi specification):
Export-Package Header Extensions Eclipse has two OSGi resolver methods -- default and strict -- that the osgi.resolver property can specify. Eclipse also includes two extensions to the Export-Package property -- x-internal and x-friends -- both of which are enforced when you enable Strict mode.
x-internal The default value for this property is false. When internal packages are specified as true using this option, the Eclipse PDE discourages their use.
x-friends This option is similar to x-internal, but allows certain bundles to use the exported packages that have this option. Others bundles are discouraged. The x-internal option takes precedence over x-friends.
Eclipse-AutoStart By default, Eclipse loads bundles on demand. Therefore, bundles are loaded when the first class they contain is required by a bundle that imports it. Specifying this value as ?? causes Eclipse to load the bundle at startup. You can also specify a list of exceptions, which are classes, and resources, and which may be loaded without starting their containing bundle.
Eclipse-PlatformFilter This property allows you to specify conditions that must evaluate to true for a bundle to start. You can include the following information in the expression you specify: osgi.nl for language osgi.os for operating system osgi.arch for architecture osgi.ws for windowing system
An example of how to use this property is to verify whether the operating system is not Mac OS X before starting a plug-in that uses the SWT_AWT bridge. (The Mac OS X implementation of the Standard Widget Toolkit (SWT) doesn't currently support this feature.)
Eclipse-BuddyPolicy This option specifies the class loading policy of the bundle. Typically, bundles only have visibility in their internal classes and those imported from dependent bundles. The popular example that has been used in the Eclipse newsgroups to explain buddy class loading is Hibernate. The Hibernate framework must see classes and resources that are user-created and not part of Hibernate itself. One such case is when you use a project to dynamically fill a class from a Hibernate Query Language (HQL) query. By default, Hibernate won't be able to see classes outside the plug-in containing the Hibernate jar files, and requiring modification of the Hibernate plug-in for the creation of each plug-in containing classes that Hibernate maps is not acceptable. Fortunately, you can solve this using the buddy class loader options explained in theBuddy class loader options section.


Back to top
Eclipse has benefited greatly in its use of OSGi, gaining a robust system managing the life cycle of components in a dynamic manner. New uses, such as dynamic Web Archive (WAR) files on the server tier featuring servlets, JavaServer Pages, and other HTTP resources in Eclipse-style plug-ins are being explored every day.
The Eclipse Foundation has positioned itself to play a key role in driving the OSGi specification forward, both for its own uses and for those of other parties leveraging OSGi. During the transition from the propriety Eclipse plug-in framework to OSGi, many additions were made to the OSGi specification that became part of the OSGi R4 specification release. The Eclipse Equinox project has, as a result, become the OSGi reference implementation moving forward. This involvement, as well as the creation of Java Specification Request (JSR) 291 to manage the evolution OSGi, guarantees that the Eclipse/OSGi partnership will continue to be successful in the years ahead.
Learn
For an introduction to Eclipse and OSGi, read "Leave Eclipse plug-in headaches behind with OSGi."
For more information about OSGi, visit theOSGi Alliance.
Wikipedia provides a good definition ofOSGi.
DiscoverOscar, an alternative OSGi implementation.
Knopflerfish is another alternative OSGi implementation.
Learn more about the EclipseEquinox project.
"EclipseCon 2006, OSGi on the Rise" describes the March 2006 EclipseCon conference, which featured OSGi prominently.
"Eclipse goes Server-side!" by Wolfgang Gehner, explains how to create Eclipse plug-ins you can deploy to servlet containers.
ReadJSR 291: Dynamic Component Support for Java SE, the JSR 291 specification.
Expand your Eclipse skills by visiting IBM developerWorksEclipse project resources.
Browse all of theEclipse content on developerWorks.
Visit the developerWorksOpen source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
Stay current withdeveloperWorks technical events and webcasts.
Get products and technologies
Innovate your next open source development project withIBM trial software, available for download or on DVD.
Discuss
Get involved in the developerWorks community by participating indeveloperWorks blogs.