作者:曹 羽中 (caoyuz@cn.ibm.com), 软件工程师, IBM中国开发中心
出处:http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-osgi/
基于 OSGi 的面向服务的组件编程
OSGi 是由 1999 年成立的 OSGi 联盟提出的一个开放的服务规范,最初的目的是为嵌入式设备,确切地说是为可以通过网络访问的设备提供一个通用的软件运行平台,屏蔽不同设备之间的硬件和操作系统差异,使软件可以动态地部署和更新。后来 Eclipse 组织注意到了 OSGi 的优点,决定将 Eclipse3.0 及后续版本的插件体系结构基于 OSGi 来实现,并专门成立了一个子项目 Equinox 来实现 OSGi R4 规范,把 Equinox 作为 Eclipse 的底层运行平台。Eclipse 组织的这一决定带来了双赢的局面,今天的 Eclipse 由于其出色的可扩展的体系结构,已经不再是一个单纯的 Java IDE,而是一个开放的开发平台,一个通用的可扩展的软件框架,OSGi 也不再局限于嵌入式领域,而是成为了一个通用的动态组件开发环境,在桌面,服务器端等领域得到了大量应用。
对模块化的支持是 Java 的一个重要的发展方向,目前 Java 的模块化标准还存在着JSR 277:Java Module Systems 和 JSR 291:Dynamic Component Support for Java 之争论,其中JSR291 的主要目的就要将 OSGi 引入到 Java 标准中去,JSR277 则是 SUN 发起的一个Java 模块化标准。但 OSGi 事实上已经得到了许多国际IT大企业的支持,并且已经有许多商业软件产品基于 OSGi 来开发,如 IBM 包括 Websphere Application Server(WAS), Rational Software Architecture(RSA) 在内的许多重量级软件产品均已基于 OSGi 来实现,现在基于 Eclipse 开发 RCP,插件程序也非常流行,可以预见基于OSGi 的 Java 应用程序将会越来越多,也将会有越来越多的软件开发组织改变其软件设计思想和开发方式,拥抱 OSGi 并开始享受 OSGi 带来的好处。
本文假设读者已经了解 OSGi 编程的基本概念以及如何在 Eclipse 环境中来开发OSGi Bundle。如果您还不了解这些知识,可以先阅读相关资料如:http://www.eclipse.org/equinox网站以及 developerworks 网站上的文章:利用 Eclipse 开发基于 OSGi 的 Bundle 应用
Eclipse 开发平台中对基于 OSGi 开发应用程序已经提供了较为完善的支持,在 Eclipse 集成开发环境中可以轻松地完成对一个或多个 bundle 的开发、调试、部署、测试等工作。本文将基于 Equinox OSGi 框架,使用 Eclipse 开发平台来开发一个示例性的系统管理程序,主要目的是给读者演示基于 OSGi 开发一个应用程序的过程并让读者体会基于OSGi 编程带来的模块化,动态性,扩展性等优点。为了便于读者理解,本文会尽可能的保持代码简单易懂,本文中的代码在 WindowsXP,Eclipse3.2,Sun JDK1.5 环境下测试通过。
OSGi 带来了规范化的模块划分,低耦合的模块间关系,统一的模块开发方式,可动态插拔的模块管理环境。开发 OSGi 应用程序的第一步是在需求分析的基础上进行精心的模块划分,模块划分的原则是尽量保持单个模块的独立性,使模块与模块之间的耦合降到最小,每一个模块暴露给其它模块的信息最少,尽量让模块之间使用 OSGi 框架提供的服务注册机制来通信。一般可采用一个模块一个 Bundle 的方式,并为每一个 Bundle 在 Eclipse 环境中建立一个 Project 来进行开发,由于模块与模块之间的耦合很小,各个 Bundle 之间并不会象传统的开发方式中的各模块之间那样存在纠缠不清的包和类的引用关系,因此大部分Bundle的开发工作可以并行进行而不会互相影响。
本文实现的系统管理程序,可以提供一系列的系统管理服务来管理计算机内的各类设备。为简便起见,我们首先只实现一项管理服务:Monitor,此项服务可以监视计算机内各类设备的运行状态,我们可以将整个软件划分为如下的一些Bundle:
- Services Bundle:在OSGi中,服务是通过Java的接口来定义的,我们可以把定义服务的Java接口集中一个Services Bundle中,并由这个Bundle向其它Bundle提供接口。
- 服务提供者Bundle:实现Services Bundle提供的接口并向OSGi框架注册服务。在本例中,我们要实现对各类设备的监视,对于每一个需要监视的设备,均可以实现一个单独的服务提供者Bundle来提供相应的监视功能。
- 服务使用者Bundle:引用Services Bundle提供的接口向OSGi框架请求相应的服务,本例中主要实现一个服务使用者Bundle,它是一个控制台程序,用于执行相应的系统管理服务,并在控制台中向用户显示相应的系统管理信息。
整个程序是由OSGi框架以及运行于OSGi框架内的一批Bundles组成,Bundle之间的协作关系见下图:
图1 程序的总体架构图
新建一个Eclipse plugin-in project,将其命名为com.systemmanagement.services,注意创建OSGi Bundle工程时,一定要选中“an OSGi framework”做为工程的目标平台,并选择Equinox或standard,这两个选项的区别是:Equinox对OSGi 规范第4版进行了一些扩展,如果开发出来的Bundle希望能够在其它的OSGi实现框架如Oscar,Knopflerfish上顺利运行,此处最好选择standard。这个Bundle的实现很简单,它无需实现BundleActivator类,只需定义一个接口即可:
代码清单1: MonitorService.java
package com.systemmanagement.services.monitor; public interface MonitorService { public String getMonitorMessage(); } |
同时勿忘在此Bundle的MANIFEST.MF文件中将相应的package导出:
代码清单2:MANIFEST.MF
Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Services Plug-in Bundle-SymbolicName: com.systemmanagement.services Bundle-Version: 1.0.0 Bundle-Vendor: cyz Bundle-Localization: plugin Export-Package: com.systemmanagement.services.monitor |
如果将来需要扩充新的系统管理服务,需在此Bundle中增加新的接口并将其所属的package在MANIFEST.MF文件中导出。
新建一个Eclipse plugin-in project,将其命名为com.systemmanagement.cpumonitor,此Bundle负责监视CPU,提供相应的监视信息,它需要实现services bundle提供的MonitorService接口,同时它需要向OSGi框架注册服务,因此首先需要在其MANIFEST.MF文件中导入相应的包:
代码清单3:MANIFEST.MF
Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Cpumonitor Plug-in Bundle-SymbolicName: com.systemmanagement.cpumonitor Bundle-Version: 1.0.0 Bundle-Activator: com.systemmanagement.cpumonitor.CpuMonitorActivator Bundle-Vendor: cyz Bundle-Localization: plugin Import-Package: com.systemmanagement.services.monitor, org.osgi.framework;version="1.3.0" |
此Bundle的实现主要包括两部分工作:一个实现MonitorService的类,用于提供CPU的监视信息(如代码清单4所示)。一个BundleActivator类用于在Bundle启动时向OSGi框架注册服务,在Bundle停止时将服务注销(如代码清单5所示)。
代码清单4:CpuMonitor.java
Package com.systemmanagement.cpumonitor.impl; import com.systemmanagement.services.monitor.MonitorService; public class CpuMonitor implements MonitorService { public String getMonitorMessage() { return "CPU--温度:40度,电压:1.4v"; } } |
代码清单4仅为演示之用途,在真正开发应用时,可以在此处实现真实的CPU监视功能,例如你可以使用Java的JNI机制来调用一些操作系统底层的或第三方的API获得相关的CPU信息,这些技术与本文的主题OSGi关系不大,在此略过。
代码清单5:CpuMonitorActivator.java
Package com.systemmanagement.cpumonitor; import java.util.Hashtable; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; import org.osgi.framework.ServiceRegistration; import com.systemmanagement.cpumonitor.impl.CpuMonitor; import com.systemmanagement.services.monitor.MonitorService; public class CpuMonitorActivator implements BundleActivator { private BundleContext context=null; private ServiceRegistration serviceRegistration=null; public void start(BundleContext context) throws Exception { this.context=context; MonitorService monitor=new CpuMonitor(); Properties properties = new Properties(); properties.put("device", "cpu"); serviceRegistration=this.context.registerService( MonitorService.class.getName(), monitor, properties); } public void stop(BundleContext context) throws Exception { serviceRegistration.unregister(); context=null; } } |
代码清单5中最重要的功能就是向OSGi框架注册了一个Monitor服务,注册服务时使用了一个Properties容器,容器中的key-value对说明了当前这个Monitor服务针对的是CPU,利用这个Properties容器,服务使用者Bundle就能够判断一个Monitor服务所针对的具体设备是什么。
针对其它需监视的设备如内存,网卡,电源,风扇等,我们可以分别实现一个Bundle来提供相应的监视服务,其实现过程与com.systemmanagement.cpumonitor这个Bundle是完全类似的,在此不再赘述。
新建一个Eclipse plugin-in project,将其命名为com.systemmanagement.console,此Bundle是一个控制台程序,它通过调用其它服务提供者Bundle提供的系统管理服务,向用户提供系统管理信息。同样首先需要在其MANIFEST.MF文件中导入相应的包:
代码清单6:MANIFEST.MF
Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Console Plug-in Bundle-SymbolicName: com.systemmanagement.console Bundle-Version: 1.0.0 Bundle-Activator: com.systemmanagement.console.ConsoleActivator Bundle-Vendor: cyz Bundle-Localization: plugin Import-Package: com.systemmanagement.services.monitor, org.osgi.framework;version="1.3.0", org.osgi.util.tracker;version="1.3.1" |
代码清单6中导入的包org.osgi.util.tracker是OSGi框架提供的监视Bundle提供的服务是否可用的机制,下文将会详述。
此Bundle的实现主要包括三部分工作:一个ServiceTracker类,用于监视服务提供者Bundle注册的各类系统管理服务是否可用,并根据服务是否可用,采取相应的动作(如代码清单7所示)。一个控制台线程类,用于执行各类系统管理服务并向用户提供相应的信息(如代码清单8所示)。一个BundleActivator类用于在Bundle启动时启动Service Tracker服务监视系统管理服务是否可用,启动控制台线程类开始执行各类系统管理服务并显示信息,在Bundle停止时停止Service Tracker服务和控制台线程类。(如代码清单9所示)。
代码清单7: MonitorServiceTracker.java
package com.systemmanagement.console; import org.osgi.framework.BundleContext; import org.osgi.framework.ServiceReference; import org.osgi.util.tracker.ServiceTrackerCustomizer; import com.systemmanagement.services.monitor.MonitorService; public class MonitorServiceTracker implements ServiceTrackerCustomizer { private ConsoleThread thread; private BundleContext bc; public MonitorServiceTracker(BundleContext bc,ConsoleThread thread) { this.thread = thread; this.bc = bc; } public Object addingService(ServiceReference reference) { MonitorService service = (MonitorService)bc.getService(reference); thread.addService(service); return service; } public void modifiedService(ServiceReference reference, Object serviceObject) { MonitorService service = (MonitorService)bc.getService(reference); thread.addService(service); } public void removedService(ServiceReference reference, Object serviceObject) { MonitorService service = (MonitorService)bc.getService(reference); thread.removeService(service); } } |
注意,在本文中只实现了Monitor一项服务,将来如需扩充到支持多项系统管理服务,可以为每一项或某一类服务各自实现一个ServiceTracker类来监视相应服务的可用性。
代码清单8:ConsoleThread.java
package com.systemmanagement.console; import java.util.HashSet; import java.util.Iterator; import com.systemmanagement.services.monitor.MonitorService; public class ConsoleThread extends Thread { private HashSet<MonitorService> monitorServices= new HashSet<MonitorService>(); private boolean running = true; public ConsoleThread(){}; public void addService(MonitorService service){ this.monitorServices.add(service); } public void removeService(MonitorService service){ this.monitorServices.remove(service); } public void run() { while (running) { for(Iterator<MonitorService> it=this.monitorServices.iterator(); it.hasNext();){ MonitorService service=it.next(); System.out.println(service.getMonitorMessage()); } try { Thread.sleep(5000); } catch (InterruptedException e) { System.out.println("ManagementThread ERROR: " + e); } } } public void stopThread() { this.running = false; try { this.join(); } catch (InterruptedException e) { e.printStackTrace(); } } } |
代码清单8是一个多线程程序,为演示之简便,在此例中它只是用一个HashSet持有当前可用的系统管理服务,并无限循环,依次执行各项系统管理服务。在实际情况中,完全可以与用户交互,根据用户的指令来执行相应的系统管理服务。
代码清单9:ConsoleActivator.java
package com.systemmanagement.console; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; import org.osgi.util.tracker.ServiceTracker; import org.osgi.util.tracker.ServiceTrackerCustomizer; import com.systemmanagement.services.monitor.MonitorService; public class ConsoleActivator implements BundleActivator { private BundleContext context = null; private ServiceTracker tracker = null; private ConsoleThread thread=new ConsoleThread(); public void start(BundleContext context) throws Exception { this.context = context; tracker = new ServiceTracker(context, MonitorService.class.getName(), new MonitorServiceTracker(context,thread)); tracker.open(); this.thread.start(); } public void stop(BundleContext context) throws Exception { tracker.close(); this.thread.stopThread(); } } |
一个基于OSGi的应用程序是由OSGi框架本身以及若干个Bundle组成,为了对其进行运行和测试,通常需要将各个Bundle Project一一打包成Bundle(jar文件),并部署到一个OSGi框架中,还是比较麻烦的。幸运的是,Eclipse已经对此提供了很好的支持,Eclipse本身是基于OSGi框架Equinox的,在Eclipse环境中可直接将各Bundle部署到Equinox框架中并运行之,对开发者来说十分便利,其具体步骤如下:
在Eclipse中选择Run-->Run...菜单,在弹出的Run配置面板的左侧选中“Equinox OSGi Framework”,然后再选择其上方的“New”按钮创建一个新的运行配置,将其命名为“systemmanagement”,再选择右侧的Deselect All按钮,然后只选择我们想要运行的4个Bundles:包括我们前面开发的3个Bundle以及OSGi框架本身org.eclipse.osgi,其中还可以设置各个Bundle的Start Level, Start Level可用于控制各Bundle的启动顺序,Start Level低的Bundle会优先启动,例如我们可以将服务提供者Bundle cpumonitor的Start Level设为1,而将服务使用者Bundle console的Start Level设为2,如下图所示:
图2 Bundle的运行配置
在Eclipse环境中的运行结果如下图,在控制台中会不断的显示一些系统管理信息,同时也可在控制台中运行各种OSGi控制台命令,如ss命令可用于显示各Bundle的状态,读者可以通过help命令了解更多的OSGi控制台命令。
图3 在Eclipse中的运行结果
我们也需要了解如何让这些Bundle脱离Eclipse环境来运行,首先需要将各个Bundle Project打包成一个Bundle(即一个jar文件),其步骤如下:
在Eclipse主菜单中选File->Export,再在弹出窗口中选择Deployable plug-ins and fragments,再选下一步,在弹出窗口中选择我们上面开发的三个Bundle project,并指定Bundle的输出目录,点Finish即可,如下图所示:
图4 导出Bundle
然后可以在e:system_managementplugins目录下找到三个jar文件,现在我们需要一个OSGi框架来运行它们。Equinox是目前最流行的OSGi框架,Equinox本身也被打包成一个Bundle,在Eclipse安装目录的plugins目录下即可找到它,如org.eclipse.osgi_3.2.0.v20060601.jar,将这个文件拷到e:system_management目录下。在命令提示符下进入e:system_management目录下,运行如下命令启动Equinox:
java –jar org.eclipse.osgi_3.2.0.v20060601.jar –console
启动之后会出现一个OSGi控制台,并且已经启动一个system bundle,这个bundle就是OSGi框架本身。现在我们可以在OSGi控制台中手工安装我们开发的三个Bundle,如下图所示:
图5 安装Bundle
随后,可以依次启动三个Bundle,这样整个应用就运行起来了,如下图所示:
图6 运行Bundle
请保留这个OSGi控制台并让应用继续运行,接下来我们还会在这个控制台中进行一些操作来体验OSGi的动态性。
除了模块化以及面向服务编程之外,OSGi的另一个重要特点是其动态性,Bundle以及Bundle提供的服务可以随时消失或者重新加入,而其它使用服务的Bundle可以感知服务是否可用,并动态地改变自己的行为。应用程序在运行过程中,可以随时增加新的Bundle,停止或卸载已有的Bundle,如果有新的服务加入进来,这个服务也能立即被其它Bundle使用并由此动态地改变整个应用程序的行为,在整个动态改变的过程中,OSGi框架本身是稳定的,无需重启。以下我们将通过一些示例来体验OSGi的动态性:
我们现在想给应用增加一个监视内存运行状态的功能,新建一个Eclipse plugin-in project,将其命名为com.systemmanagement.memorymonitor,这个Bundle的实现过程与com.systemmanagement.cpumonitor基本类似,最主要的不同是实现MonitorService服务的那个类,如以下代码所示,其它代码可参见本文所附的代码清单。
代码清单10:MemoryMonitor.java
package com.systemmanagement.memorymonitor.impl; import com.systemmanagement.services.monitor.MonitorService; public class MemoryMonitor implements MonitorService { public String getMonitorMessage() { return "内存--物理内存总数:1G,可用数:300M"; } } |
同样,将这个Bundle export成一个jar文件到e:system_managementplugins目录下,安装以及启动这个Bundle,这时我们发现输出的系统管理信息马上改变了,如下图所示:
图7 安装以及启动一个新的Bundle
再假定我们需要增强com.systemmanagement.cpumonitor这个Bundle的功能,让其提供更多的CPU信息,我们可以修改其中的CpuMonitor.java类,如下所示:
代码清单11:CpuMonitor.java
package com.systemmanagement.cpumonitor.impl; import com.systemmanagement.services.monitor.MonitorService; public class CpuMonitor implements MonitorService { public String getMonitorMessage() { return "CPU--温度:40度,电压:1.4v,CPU占用率:20%"; } } |
再将这个Bundle export成一个jar文件,放到e:system_managementplugins目录下,并在OSGi控制台中使用update命令更新这个Bundle,我们发现输出的CPU监视信息马上改变了,如下图所示:
图8 更新Bundle
读者还可以在OSGi控制台中尝试使用start,stop等命令启动和停止一些Bundle,观察输出信息的改变,由此来体验一下OSGi的动态性。
由于基于OSGi的应用程序具有高度的模块化和动态性的特点,使得要对其进行扩展也变得非常的方便:一般来说,扩展就是增加新的Bundle,对其它Bundle基本无影响,如上面的例子所示,我们很方便地为应用程序增加了新的功能,更新了它已有的功能,而整个应用程序甚至都不需要重启。Equinox同时还借用了Eclipse中的扩展点的机制,利用扩展点,可以方便的为已有的Bundle扩展功能,但扩展点这一套机制目前还不是OSGi规范中定义的特性,仅是Equinox这一实现平台扩展出来的功能,使用了扩展点的Bundle将有可能不能在其它的OSGi实现框架中正常运行,这需要开发者权衡选择。
在上一节中我们在OSGi控制台中运行我们的系统管理程序,其中还需要手工install, start各个Bundle,显然这很麻烦,不太象一个真正的应用程序,本节将介绍如何构造出一个完整的基于OSGi的应用程序。
首先,Equinox提供了在启动框架时自动安装Bundle以及启动Bundle的功能,这是通过定义config.ini文件来实现的,应用程序的目录结构如下:
E:SYSMGT_APP1 │ run.bat │ org.eclipse.osgi_3.2.0.v20060601.jar ├─configuration │ config.ini └─plugins com.systemmanagement.console_1.0.0.jar com.systemmanagement.cpumonitor_1.0.0.jar com.systemmanagement.services_1.0.0.jar |
config.ini文件的内容如下:
osgi.bundles=plugins/com.systemmanagement.cpumonitor_1.0.0.jar@1:start, plugins/com.systemmanagement.console_1.0.0.jar@2:start, plugins/com.systemmanagement.services_1.0.0.jar |
其中的@1,@2用于指定Bundle的Start Level, start表示当OSGi框架启动后即自动启动此Bundle。而run.bat是一个批处理程序,其内容如下:
java –jar org.eclipse.osgi_3.2.0.v20060601.jar -console
现在只需运行run.bat即可运行我们的系统管理应用程序了。
Eclipse中还提供了两个Bundle, org.eclipse.equinox.common和org.eclipse.update.configurator,可用于自动发现和安装指定目录下新增加的Bundle。我们同样可以在Eclipse的plugins目录中找到这两个Bundle并将它们拷到E:SYSMGT_APP1plugins目录下,并修改config.ini文件的内容如下所示:
osgi.bundles=plugins/org.eclipse.equinox.common_3.2.0.v20060603.jar@1:start, plugins/org.eclipse.update.configurator_3.2.0.v20060605.jar@2:start, plugins/com.systemmanagement.cpumonitor_1.0.0.jar@2:start, plugins/com.systemmanagement.console_1.0.0.jar@3:start |
这样,当org.eclipse.update.configurator Bundle启动时,它会去自动发现和安装plugins目录新增的Bundle,但需注意,它并不能自动启动这些Bundle,OSGi协议目前也没有提供这样的标准服务来自动安装,管理和启动Bundle,我们可以使用如下的一些解决方案来更好地管理和分发Bundle:
- 利用Eclipse的Update Manager:Eclipse Update Manager提供了一批API用于管理,下载,升级,安装Feature,一个Feature是一批Bundle的集合, 是下载和安装的最小单位。但Feature是Eclipse定义的,不是OSGi协议中定义的特性。
- 使用FileInstall Bundle,这个Bundle可以监视某一个目录,如果这个目录中新增加了Bundle,它会自动将其install,如果有Bundle被更新了,它会自动将其update,如果有Bundle从此目录被移走,它会自动将其uninstall。可到http://www.aqute.biz/Code/FileInstall下载这个Bundle,它可以运行于任何OSGi框架中。
- 在Equinox孵化器(incubator)中有一个org.eclipse.equinox.simpleconfigurator,可用于管理和控制已安装的Bundle,包括设置启动级别并自动启动它们。可访问http://www.eclipse.org/equinox/incubator并到其CVS库中下载
本文介绍了基于OSGi开发一个应用程序的完整流程,包括模块划分,Bundle的设计与开发,部署与测试,发布应用程序等,并演示了基于OSGi编程所具有的模块化,面向服务,动态性,易扩展等优点。基于组件或构件编程是学术界提了多年的思想,笔者认为OSGi是一个比较彻底地体现这种思想的编程模型,基于OSGi编程将带来软件设计以及开发方式的改变并由此带来软件生产效率的极大提升。
申明:本文仅代表笔者个人的观点,不代表IBM公司的观点。
描述 | 名字 | 大小 | 下载方法 |
---|---|---|---|
本文所有的示例源代码 | osgi_samplecodes.zip | 27KB | HTTP |
学习
- IBM developerworks中国网站上的文章
利用Eclipse开发基于OSGi的Bundle应用
- 阅读Scott Delap撰写的
了解Eclipse插件如何使用OSGi
- 要了解Eclipse和OSGi,请阅读
利用OSGi解决Eclipse插件难题
- 访问 OSGi Alliance Service Platform, 了解更多关于 OSGi的信息,包括OSGi Release 4规范等信息
- 获得有关Eclipse和Equinox的更多详细资料 Eclipse.org,Equinox
- 了解其它OSGi实现框架: Oscar,Apache Felix,Knopflerfish
- 要获得关于Eclipse平台的介绍性文章,请参阅
Eclipse 平台入门
- EclipseCon 上有许多关于OSGi的资料
讨论
补充:
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 |
OSGi R4 框架核心目前的规范草案几乎有 PDF 格式的 300 页。介绍该规范的每个部分超出了本文范围,但我将讨论开发人员特别感兴趣的 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
- 该属性指定要在给定绑定包中导入使用的绑定包及其已导出的包。指定的绑定包在显式包导入之后解析。