RCP: MANIFEST.MF, plugin.xml, build.properties三种文件的区别

在Eclipse插件开发中， MANIFEST.MF, plugin.xml, build.properties是三种最常见的文件，由于它们共享同一个编辑器（Plug-in Manifest Editor)，经常会有插件开发者误解、混淆了这三个文件的用途。我们来看看这三个文件有哪些区别。

1、在编辑器上的区别

我们来看看Plug-in Manifest Editor是什么样子的：

上图是manifest编辑器的Overview签页的项目。注意编辑器的底部，有多个签页。

其中，Overview、Dependencies、Runtime，三个签页是MANIFEST.MF文件的图形化编辑器。

Extensions、Extension Points，两个签页是plugin.xml文件的图形化编辑器。

Build签页则是build.properties文件的图形化编辑器。

最后的三个签页MANIFEST.MF、plugin.xml、build.properties分别为对应文件的文本编辑器。

2、功能上的区别

我们知道，静态文本通常用来作为配置文件。

MANIFEST.MF对于Java程序员来说是个常见的文件（不知道的回去面壁），它用来标识当前jar包的各种属性的，如果你做过“可双击启动的jar包”，应该能想起这个文件。

MANIFEST.MF里有一般属性，也有一些和其他体系约定俗称的属性，也可以添加自定义的属性。

比如在插件开发里，一个插件项目的MANIFEST.MF基本会具备如下属性：

有些插件开发者会疑惑。为什么同样是一个jar包，有些会被Eclipse认同为bundle（不懂这个词的插件开发者去面壁），有些只能认同为普通的jar。

这个MANIFEST.MF的内容就是关键了，普通的jar包是不会具备这些bundle信息的。

在Eclipse（具体来说是equinox）找到这个插件jar的时候，会读取其MANIFEST.MF文件，以获取其名称，版本号，依赖关系，等。

然后完成我们所知的插件加载过程。

即是说，MANIFEST.MF是用来配置插件的元信息的，其属性的名和值，需要符合OSGi规范。

OSGi以MANIFEST.MF为依据，来启动插件，计算依赖性，决定约束（constraint）等等，其他的OSGi框架比如felix，也可以读取识别它。

该文件的使用发生在插件加载之前。

plugin.xml是为Eclipse的扩展点和扩展服务的。

很多人混淆了扩展点和扩展的概念。

下图所做的操作，相信插件开发人员都做过：

这一系列的完整的操作，我们应该称之为“选择了org.eclipse.ui.editors扩展点，并添加了一个扩展”

扩展点，即是Extension Point，扩展点本身其实不具备功能，它仅仅只是个“格式规范”，一个“schema”，本质上，它是个类DTD定义。

扩展，即是Extension，它是真正的配置项（XML格式），用户根据扩展点的约束填入合适的值，以完成配置。

这里不会赘述一个扩展是如何生效的，有兴趣的同学可以尝试自己定义一个“扩展点”，然后完善它的exsd定义文件。

在代码里查询扩展点内容使用如下代码：

Platform.getConfigurationElementsFor(String extensionPointId);

如此可知，plugin.xml是为了扩展点和扩展服务的，是Eclipse的专属内容。它的使用发生在插件被加载之后。

build.properties，属性文件相信大家并不陌生，插件在打包的过程中，需要提供给ant脚本一些变量，这些变量就记录在build.properties文件中。

该文件会在插件或者产品导出的时候使用到。