关于MANIFEST.MF的理解

打开Java的JAR文件我们经常可以看到文件中包含着一个META-INF目录，这个目录下会有一些文件，其中必有一个MANIFEST.MF，这个文件描述了该Jar文件的很多信息.

在Java平台中, Manifest资源配置文件是JAR档案文件中包含的特殊文件。Manifest文件被用来定义扩展或档案打包相关数据。Manifest文件是一个元数据文件，它包含了不同部分中的名/值对数据。如果一个JAR文件被用来作为可执行文件，那么其中的Manifest文件需要指出该程序的主类文件。通常Manifest文件的文件名为MANIFEST.MF。 通常Manifest文件都与Java档案相关，其他的情况比较少见

先来看看struts.jar中包含的MANIFEST.MF文件内容：

　　Manifest-Version: 1.0
　　Created-By: Apache Ant 1.5.1
　　Extension-Name: Struts Framework
　　Specification-Title: Struts Framework
　　Specification-Vendor: Apache Software Foundation
　　Specification-Version: 1.1
　　Implementation-Title: Struts Framework
　　Implementation-Vendor: Apache Software Foundation
　　Implementation-Vendor-Id: org.apache
　　Implementation-Version: 1.1
　　Class-Path: commons-beanutils.jar commons-collections.jar commons-digester.jar commons-logging.jar commons-validator.jar jakarta-oro.jar struts-legacy.jar
如果我们把MANIFEST中的配置信息进行分类，可以归纳出下面几个大类：

如果我们把MANIFEST中的配置信息进行分类，可以归纳出下面几个大类：
一. 一般属性
1. Manifest-Version
用来定义manifest文件的版本，例如：Manifest-Version: 1.0
2. Created-By
声明该文件的生成者，一般该属性是由jar命令行工具生成的，例如：Created-By: Apache Ant 1.5.1
3. Signature-Version
定义jar文件的签名版本
4. Class-Path
应用程序或者类装载器使用该值来构建内部的类搜索路径

二. 应用程序相关属性
1. Main-Class
定义jar文件的入口类，该类必须是一个可执行的类，一旦定义了该属性即可通过 java -jar x.jar来运行该jar文件。
三. 小程序(Applet)相关属性
1. Extendsion-List
该属性指定了小程序需要的扩展信息列表，列表中的每个名字对应以下的属性
2. <extension>-Extension-Name
3. <extension>-Specification-Version
4. <extension>-Implementation-Version
5. <extension>-Implementation-Vendor-Id
5. <extension>-Implementation-URL
四. 扩展标识属性
1. Extension-Name
该属性定义了jar文件的标识，例如Extension-Name: Struts Framework
五. 包扩展属性
1. Implementation-Title 定义了扩展实现的标题
2. Implementation-Version 定义扩展实现的版本
3. Implementation-Vendor 定义扩展实现的组织
4. Implementation-Vendor-Id 定义扩展实现的组织的标识
5. Implementation-URL : 定义该扩展包的下载地址(URL)
6. Specification-Title 定义扩展规范的标题
7. Specification-Version 定义扩展规范的版本
8. Specification-Vendor 声明了维护该规范的组织
9. Sealed 定义jar文件是否封存，值可以是true或者false (这点我还不是很理解)
六. 签名相关属性
签名方面的属性我们可以来参照JavaMail所提供的mail.jar中的一段
Name: javax/mail/Address.class
Digest-Algorithms: SHA MD5
SHA-Digest: AjR7RqnN//cdYGouxbd06mSVfI4=
MD5-Digest: ZnTIQ2aQAtSNIOWXI1pQpw==
这段内容定义类签名的类名、计算摘要的算法名以及对应的摘要内容(使用BASE64方法进行编码)
七.自定义属性
除了前面提到的一些属性外，你也可以在MANIFEST.MF中增加自己的属性以及响应的值，例如J2ME程序jar包中就可能包含着如下信息
MicroEdition-Configuration: CLDC-1.0
MIDlet-Name: J2ME_MOBBER Midlet Suite
MIDlet-Info-URL: http://www.javayou.com/
MIDlet-Icon: /icon.png
MIDlet-Vendor: Midlet Suite Vendor
MIDlet-1: mobber,/icon.png,mobber
MIDlet-Version: 1.0.0
MicroEdition-Profile: MIDP-1.0
MIDlet-Description: Communicator
关键在于我们怎么来读取这些信息呢？其实很简单，JDK给我们提供了用于处理这些信息的API，详细的信息请见java.util.jar包中，我们可以通过给JarFile传递一个jar文件的路径，然后调用JarFile的getManifest方法来获取Manifest信息。

>>>>>>>>>>>>>>>>>>OSGi  MANIFEST.MF 文件详解>>>>>>>>>>>>>>>>>>>>>>>>>

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

该属性指定要在给定绑定包中导入使用的绑定包及其已导出的包。指定的绑定包在显式包导入之后解析。

关于这里讲解的Important-Package和Require-Bundle之间的关系我想到了在工作中有个重构的单子,强哥专门给我讲解了一下这个两者的区别.关于这个在我的重构的博文中也有将,这里再说一遍!

我不知道在重构的过程中是怎么把右侧的Imported Package加上的.好囧......自己做的都不知道是怎么加上的了......

现在我要一个个check各个插件然后删除这些多余的Improt Package.

为什么是多余的呢?

因为在Require-Bundle中已经有对这Important Package的引用了.所以要删除,为什么多余就要删除呢?

下面是强哥的解释.....

我理解是，require bundle是显式依赖，明确告诉plugin，你依赖那些插件
而import package是隐形依赖，即会自动查找所有已经挂载的插件，并找到对应的包，里去找class
如果挂载的不同的两个插件有相同包，并且有相同的名字的class，势必出问题

当然有时候，确实有这方面的模糊依赖，就用import package

否则最好用显式依赖，明确点好

之前我接触到一个单，就是因为这个问题，导致我们重构了不少代码，避免相同包存在

嗯，有些是多余，有的插件里，你没有require bundle

因为仍旧工作，是因为两者你选择了其一就能工作,同时在，也没有问题

恩,知道了.删除多余的import package之前 我确认下require bundle中是否有org.talend.repository.view.di

对，都统一required bundle方式

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Eclipse 提供的其他清单选项

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 地图不可接受的类的每个插件。幸运的是，伙伴类加载器选项 一节中介绍的伙伴类加载器选项解决了这个问题。

伙伴类加载器选项

首先为 Hibernate 创建插件。然后创建一个插件，其中包含与 Hibernate 有依赖关系的特定于域的类。将下列行添加到 Hibernate 插件清单中：Eclipse-BuddyPolicy: registered。

将下列清单属性添加到包含特定于域的类或资源的插件清单中： Eclipse-RegisterBuddy: hibernate。

该行允许插件通过声明将自己暴露给 Hibernate 插件，而它预先并不知道这些插件。现在，Hibernate 插件可以看到需要的类，虽然它并没有专门导入它们。

http://blog.sina.com.cn/s/blog_4a684db40100y0xr.html

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>