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

前端之家收集整理的这篇文章主要介绍了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文件中。

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




原文转载自:http://www.cnblogs.com/anrainie/p/3573090.html

猜你在找的XML相关文章