简介： 产品发布后，经常需要提供给用户一些临时的或小的补丁程序来修正用户在使用中碰到的问题 。Feature Patch 是实现插件更新的一种灵活方式，本文中主要讲解了对基于 Equinox 的 RCP 如何创建 、部署 Feature Patch 并为部署后的出现的问题，提供了解决思路。
如果用户在使用过程中发现了产品中的问题，对于研发人员来说，一种解决方案是在下一个发布版本 中包含对这些问题的修改。但是如果问题非常紧急，甚至影响了客户的正常工作，通常的做法是创建临时 的补丁程序，然后安装到用户的生产环境中。对于基于 Eclipse 的 RCP 产品而言，产品的升级就是插件 功能的改进即插件版本的提高。在创建了新版本的插件后，如何交付给用户呢？一种方法是用户通过 Software Update 界面指定 Update Site 进行安装。但是这种机制对于商业化的产品或者对于产品小的 改动而言较为笨重，同时由于产品环境是由安装软件定制的，通过 Software update 界面可能无法完成 安装。本文介绍了一种通用的方法，创建并部署 Feature Patch，能够比较灵活的解决问题。
Feature 及 Feature Patch 的概念
Plug- in（插件，OSGI 中的 bundle）包含了产品功能的 具体实现，但从整个产品的角度看粒度较小，不利于管理。Feature( 功能部件 ) 能将功能相近的插件组 织起来，用户管理的是一个个的功能模块，而不需要具体的实现细节，使整个产品的结构层次化。通过使 用 Feature 来打包插件，可以做到：
1. 列出所有的前提条件，方便 Eclipse 的配置管理
2. 使用 Eclipse Software update 来对插件进行管理
3. 支持品牌化管理，可以在 feature 中定义一个欢迎页面，让用户对插件的功能更加熟悉。
尽管简单的拷贝 Plug-in 到 eclipse 的 Plugins 目录也能生效，但是这些插件是不被管理的，这种做法是不推荐的。同时如果基于 Eclipse 的 RCP 配置为基于 Feature 进行安装、升级，那么只是生成并拷贝高版本的插件，并不能生效 ，对于这种场景，就需要以 Feature 为单位来创建补丁程序即 Feature Patch。
Feature Patch 是 Eclipse 支持的一种工程类型，与 Feature 工程结构类似，并不实际参与 Eclipse 启动过程，在 Feature Patch 中会指定对哪个 Feature 创建补丁，特点包括
一般比较小，且必须指定对哪个 Feature 创建补丁
Feature Patch 只包含需要更新的插件，部署后只会对已存在 Feature 中的部 分插件进行更新
为简化补丁机制，本文采取增量式补丁，即每个 feature 只包含一个 feature patch 程序。举例来说，假设 Feature A 已经包含了补丁程序 B，那么下次发布的补丁程序应该包含了 补丁程序 B 中的修改。
Eclipse 插件的版本规范
在创建 Feature patch 过程中，会更改 插件的版本，这就需要读者了解插件的版本规范。在 Eclipse/plugins 目录下的插件名字大都为 org.eclipse.equinox.p2.engine_1.0.4.v20080930.jar 类似结构，其中 org.eclipse.equinox.p2.engine 为此插件的 ID，而下划线后面的为此插件的版本号。在 Eclipse 中， 插件的版本号由四部分组成：major.minor.service.qualifer
表 1. Eclipse 插件版本规范
| 部分名 | 什么时候改变 |
| major | 当产品的 API 发生大的变化时，major 部分应该增加，当 major 部分变化时，minor 和 service 部分应该置 0 |
| minor | “外部能够看到”的改变，比如说重要的性能改进，主 要代码重写 |
| service | 不同发布版本之间的插件发生改变，比如代码中的 bug fix，编译选项设置改变 |
| qualifier | 不同 Build 之间的变化 |