OSGI Bundle元数据常用标记

2019独角兽企业重金招聘Python工程师标准>>>

Bundle的元数据信息定义在/META-INF/MANIFEST.MF文件之中，OSGi规范中明确要求实现框架必须能够正确识别那些被预定义过的 标记（在R5.0规范中预定义了28项标记），对于不可识别的标记以及不符合MANIFEST.MF标记格式的内容都要忽略且不能影响Bundle的正常 解析。

以下列出了MANIFEST.MF文件中常用的预定义标记，所列举的标记项都是可选的

（1）Bundle-ActivationPolicy

标记Bundle-ActivationPolicy设置Bundle的加载策略，该参数目前只有一个值：lazy，设置该参数后，Bundle将 延迟激活，延迟至有其他的Bundle请求加载该Bundle中的类或资源时它才会被激活，如果不设置这个参数，那么Bundle启动时就会被激活。

示例：

Bundle-ActivationPolicy: lazy

（2）Bundle-Activator

标记Bundle-Activator指明一个Activator 类，在Bundle启动和停止时会分别调用该类的start()和stop()方法，以便执行程序员所希望的动作，该类必须实现 org.osgi.framework.BundleActivator接口。 Activator类通常用于在Bundle启动时注册和初始化服务，在Bundle卸载时注销这些服务。它很常用，但并不是必须的。

示例：

 Bundle-Activator: com.acme.fw.Activator

（3）Bundle-Category

标记Bundle-Category指明该Bundle的功能类别，可使用逗号分隔多个类别名称。这个功能类别仅供人工分类和阅读，OSGi框架并不会使用它。

示例：

Bundle-Category: osgi, test, nursery

（4）Bundle-ManifestVersion

标记Bundle-ManifestVersion指出该Bundle应遵循哪个版本的OSGi规范，默认值为1。对于OSGi R3规范，该值为1；对于OSGi R4/R5规范，该值为2。也可能在以后的OSGi规范中使用更高的数字,但现在仅允许将它设置为1或2。

示例：

Bundle-ManifestVersion: 2

（5）Bundle-Name

标记Bundle-Name定义该Bundle的名称。注意该名称只供人工阅读，在Bundle-SymbolicName标记中定义的名称才会作 为程序使用的Bundle的唯一标识来使用。根据一般开发习惯，Bundle-Name中所定义的名称会在打包发布时与Bundle-Version一起 构成该Bundle的文件名，所以这个名称一般不含空格或其他不能在文件名中出现的字符。

（6）Bundle-NativeCode

如果Bundle中需要使用JNI加载其他语言实现的本地代码，那么必须使用Bundle-NativeCode标记进行说明。这个标记有如下附加参数：

• osname：操作系统名称，如Windows等。
• osversion：操作系统版本号，如3.1等。
• processor：处理器指令集架构，如x86等。
• language：遵循ISO编码的语言，如en，zh等。
• seleciton-filter：选择过滤器，该值为一个过滤器表达式，指定被选中或未被选中的本地代码。 示例： Bundle-NativeCode: /lib/http.DLL; osname = QNX; osversion = 3.1

（7）Bundle-RequiredExecutionEnvironment

标记Bundle-RequiredExecutionEnvironment定义该Bundle所需的执行环境，支持多种执行环境的Bundle 使用逗号分隔。OSGi在设计上就有非常广泛的应用范围，从嵌入式系统至大型服务器执行环境必然会有许多差异，因此在这个标记中需要指出该Bundle所 适合的执行环境。在后续章节中我们还会继续介绍OSGi执行环境。 示例： Bundle-RequiredExecutionEnvironment: CDC-1.0/Foundation-1.0

（8）Bundle-SymbolicName

标记Bundle-SymbolicName给出该Bundle在OSGi容器中的全局唯一标识符。与其他可选标记不同，这个标记没有默认值，并且 是Bundle元数据信息之中唯一一个必须设置的标记。程序将基于此标记和版本号在OSGi容器中定位到一个独一无二的Bundle。 当且仅当两个Bundle的Bundle-SymbolicName和Bundle-Version属性都相同的时候，它们才是完全相同的，不允许同时安 装两个完全相同的Bundle到同一个OSGi容器之中。 Bundle-SymbolicName有以下两个附加参数。 singleton：表示Bundle是单例的。如果OSGi系统中同时存在两个Bundle-SymbolicName相同的（当然，要求 Bundle-Version不相同，否则是不可能同时存在的）单例Bundle，那么仅有其中一个会被解析。如果其中一个没有声明为单例Bundle， 则不会受到另外一个单例Bundle的影响，默认值为false。 fragment-attachment：定义Fragment Bundle是否能附加到该Bundle之上。允许值为always、never和resolve-time，含义为允许附加、禁止附加和只允许在解析过 程中附加，默认值为always，即允许附加。 示例： Bundle-SymbolicName: com.acme.daffy

（9）Bundle-UpdateLocation

标记Bundle-UpdateLocation给出Bundle的网络更新地址。如果Bundle需要更新版本，将使用这个地址。 示例： Bundle-UpdateLocation: http://www.acme.com/Firewall/bundle.jar

（10）Bundle-Vendor

标记Bundle-Vendor给出该Bundle的发行者信息。 示例： Bundle-Vendor: OSGi Alliance

（11）Bundle-Version

标记Bundle-Version给出该Bundle的版本信息，默认值为“0.0.0”。注意，这项信息并不是仅供人工阅读的，“版本”在 OSGi中是一项受系统管理的信息。维护一个Bundle的不同版本也是运行OSGi框架的重要特征之一，当一个Bundle依赖另一个Bundle时， 经常需要指明它依赖的是什么版本范围内的Bundle。 版本号是有序的，在Symbolic-Name相同的前提下，两个Bundle的版本可比较大小。完整的版本号会由“主版本号（Major）”+“副版本 号（Minor）”+“微版本号（Micro）”+“限定字符串（Qualifier）”构成。 示例： Bundle-Version: 22.3.58.build-345678 根据一般的开发习惯，上述4项版本号约定俗成地表示如下含义。

• 主版本号：表示与之前版本不兼容的重大功能升级。
• 副版本号：表示与之前版本兼容，但可能提供新的特性或接口。
• 微版本号：表示API接口没有变化，只是内部实现改变，或者修正了错误。
• 限定字符串：通常用于表示编译时间戳或者编译次数。

在比较版本大小时，从前往后逐项（含限定字符串）进行比较，当且仅当4个比较项都对应相等，两个Bundle的版本才相等，否则以第一个出现差异的版本号的大小决定整个Bundle版本的大小。 示例： 1.2.3 < 3.2.1 < 4.0 有一点必须注意，对于限定字符串的处理，OSGi和Maven是恰恰相反的，在Maven里，版本“1.2.3.2012”<=“1.2.3”，但在OSGi里则是版本“1.2.3.2012”>=“1.2.3”。

（12）DynamicImport-Package

标记Dynamic Import-Package描述运行时动态导入的Package。Package的导入和导出构成了OSGi多模块之间的组织协作关系，这是一个相对复杂而又很重要的内容，我们将在后续章节中专门介绍。 示例： DynamicImport-Package: com.acme.plugin.*

（13）Export-Package

标记Export-Package描述被导出的Package。导入导出Package是模块层的核心功能，该内容将在后续章节中具体介绍。 示例： Export-Package: org.osgi.util.tracker;version=1.3

（14）Export-Service

标记Export-Service描述被导出的服务，这个标记在OSGi规范中已经被声明为Deprecated了，不推荐继续使用此标记。 示例： Export-Service: org.osgi.service.log.LogService

（15）Fragment-Host

当该Bundle是一个Fragment Bundle时，标记Fragment-Host指明它的宿主Bundle。 示例： Fragment-Host: org.eclipse.swt; bundle-version="[3.0.0,4.0.0)"

Fragment Bundle是一种特殊的Bundle，它无法独立存在，必须依附于某个其他的普通Bundle来使用，可以将它视为“Bundle的插件”、“模块中的模块”。

Fragment Bundle经常用来提供某些可选的功能，譬如为某个实现具体功能的Bundle提供一个中文语言包。有这个语言包，实现功能的Bundle能显示中文界 面；在没有这个中文语言包时，实现功能的Bundle也能够正常使用。Fragment Bundle的另一项主要用途是隔离Bundle中经常变动的部分，譬如把系统的内部配置文件（开发模式还是生产模式、连接的数据库地址、调试级别等）集 中在Fragment Bundle中，通过更换不同的Fragment Bundle来实现配置快速切换。

从静态角度（开发期）来看，Fragment Bundle与普通Bundle没有太大区别，它们都以JAR文件格式为基础，具备相同的元数据信息标记，标记的含义与设置方式也一样。区别仅仅是 Fragment Bundle的元数据中会使用Fragment-Host标记说明它的宿主Bundle。

从动态角度（运行期）来看，Fragment Bundle与普通Bundle在运行时的处理差别却非常大，最重要的一点差异是Fragment Bundle不具备自己独立的类加载器。OSGi利用每个Bundle独立的类加载器互相协作来维护Bundle间导入、导出的依赖关系。没有类加载器， 就无法直接与其他Bundle交互，必须依附于宿主，使用宿主Bundle的类加载器完成。关于这部分内容，我们在后面会有更详尽的介绍。

（16）Provided-Capability

标记Provided-Capability描述该Bundle提供的服务特性（Capability）。服务特性是在OSGi R4.3规范中加入的新概念。在此之前，Bundle只能通过Bundle-RequiredExecution-Environment来声明所需的执 行环境；但是在某些场景下一些执行环境特性是由其他Bundle提供的，这样依赖运行环境来描述所需特性就受到限制了。因此在R4.3规范中加入了 Provided-Capability和Require-Capability来声明Bundle所需要和能够提供的特性。 示例： Provided-Capability: com.acme.dict; from=nl; to=de; version:Version=1.2

（17）Import-Package

标记Import-Package是package级别的导入，描述该Bundle需要导入的Package。导入导出Package是模块层的核心功能，该内容将在后续章节中具体介绍。 示例： Import-Package:org.osgi.service.io;version=1.4

（18）Import-Service

标记Import-Service描述导入的服务。这个标记在OSGi规范中已经被声明为Deprecated了，不推荐继续使用此标记。 示例： Import-Service: org.osgi.service.log.LogService

（19）Require-Bundle

标记Require-Bundle描述该Bundle所依赖的其他Bundle，一旦声明了依赖某个Bundle，就意味着可以直接使用所有从这个Bundle中导出的Package。 示例： Require-Bundle: com.acme.chess

Require-Bundle ：是bundle级别的导入，表示导入了这个Bundle中所有声明的导出的Package，后面跟一个或多个Bundle名称（由Bundle-SymbolicName定义的名称），多个名称的话用逗号分隔，但不建议使用。

 

 

转载于:https://my.oschina.net/luyaolove/blog/736190