了解 Eclipse 插件如何使用 OSGiEclipse 和 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)级别的服务注册,该绑定包可用于发布、发现和绑定至服务。 图 1. 主机操作系统、Java 和 OSGi 中层的交互 ![]() 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 插件的代码段。 清单 1. org.eclipse.pde 插件中的代码段
接下来两部分定义了 org.eclipse.pde.ui 可用于其他插件的扩展点以及它对其他插件的贡献。在本例中,可以看到自定义 Eclipse Plug-in Development Environment(PDE)视图的定义。 下面来看 Eclipse V3.1 中的同一插件定义。清单 2 展示了 plugin.xml 文件。 清单 2. Plugin.xml
注意,导出和导入信息不见了。该信息现在位于清单 3 所示的 manifest.mf 文件中。 清单 3. Manifest.mf
各种插件导入现在被指定为必需的绑定包,* 包导出已经替换为显式导出的包列表。 插件级的依赖关系改为需要显式导出和导入包的依赖关系,当 Eclipse 宣布这个消息时,曾引起大量骚动。主要抱怨的是缺乏已经存在于 Eclipse 早期版本中的
OSGi R4 框架核心目前的规范草案几乎有 PDF 格式的 300 页。介绍该规范的每个部分超出了本文范围,但我将讨论 Eclipse 插件开发人员特别感兴趣的 OSGi manifest.mf 选项:
OSGi 规范包括的 manifest.mf 配置选项不提供 Eclipse 平台需要的所有功能。因此,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 合作伙伴关系将在未来几年里不断取得成功。 学习
获得产品和技术
讨论
|
Understanding how Eclipse plug-ins work with OSGiEclipse and OSGi from A to Z, or in this case, plugin.xml to manifest.mf ![]() | ![]() |
![]() |
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.
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. Figure 1. The interaction of the layers in the host operating system, Java, and OSGi ![]() 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.
Implementing Eclipse using OSGi 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. Listing 1. Excerpt from the org.eclipse.pde plug-in
The 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. Listing 2. Plugin.xml
Notice that the export and import information is gone. This information now resides in the manifest.mf file shown in Listing 3. Listing 3. Manifest.mf
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
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:
Additional manifest options provided by Eclipse
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):
Future directions of Eclipse and OSGi 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
Get products and technologies
Discuss
|
联系客服