簡介： 產品發布後，經常需要提供給用戶一些臨時的或小的補丁程序來修正用戶在使用中碰到的問題 。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 之間的變化
當 Eclipse 檢測到有多個版本的，會根據下列規則決定去加載哪個插件：
加載 major 部分數字最大的插件
若 major 部分相等，則加載 minor 部分數字最大的插 件
若 minor 也相同，則加載 service 部分數字最大的插件
若 service 相同，則加載 qualifier 部分 ASCII 碼最大的插件
由於 Feature 包含了一些插件，所以 Feature 的版本變化 應反映了它所包含的插件與 Feature 中最典型的變化，即：如果任何它所包含的插件與 Feature 版本的 major/minor/service/qualifer 發生變化，需要增加這個 Feature 相應的字段。
在 feature.xml 中定義依賴性時有一個重要的屬性 match rule，它定義了 Eclipse 使用的版本過濾算法（ 只有當 match rule 得到滿足時才能進行 Install 或 Update 功能部件操作），Match rule 主要有以下 幾個可選值：
表 2. match rule 取值范圍及說明
Rule 功能說 明 perfect 必須和執行的版本號完全一樣 equivalent major 和 minor 部分相同，service 部分需大於或等於指定的 版本號 compatible major 部分相同，minor 或 service 部分需大於或等於 指定的版本號 greaterOrEqual major 或 minor 或 service 部分需大於或 等於指定的版本號創建 Feature Patch
本章節將會介紹怎樣通過 Eclipse 提供的 Feature Path 向導來創建 feature patch。在此之前，需要首先創建示例所需要的 feature.
使用“Plug-in with view”創建一個新的 Plug-in 工程 “cn.myplugin”，版本為 1.0.0_v20091225
創建新 Feature 工程 “cn.myfeature”，版本為 1.0.0，添加上面創建的插件到此 feature
然後可以將 “cn.myfeature“工程導出為“Deployable features“，拷貝生成文件到 eclipse 相應目錄下來驗證 Feature 是否創建成功。
步驟 1：收集與 Patch 相關的信息
在創建 Patch 前，需要明確以下信息：
哪些插件需要更新（本例中為 cn.myplugin）
這 些插件屬於哪些 feature，及這個 feature 的版本號 ( 本例中為 cn.myfeature_1.0.0)
是不是 已經對這個 Feature 創建過 Patch
是否有插件需要在安裝的時候進行解壓縮
步驟 2：更 新插件的版本信息
根據需求，更改完插件代碼後，下一步需要通過更改插件版本號將插件標識為 新版本的插件。對於一些臨時的或比較小的補丁程序時，修改插件版本號中的 qualifier 部分就可以了 。對於一個比較大的 fix pack 版本才會去更新版本號的 service 部分。此例中，將 cn.myplugin 的版 本改為 1.0.0.v20100101
步驟 3：利用“Feature Patch”向導創建 Feature Patch
通過 File -> New -> Others -> Plug-in Development，創建“Feature Patch”工程，
圖 1. Feature Patch 向導
填寫跟 Feature Patch 屬性信息。Project Name 和 Patch ID 基於被應用 Patch 的 Feature，一般以 feature ID 加 .patch 作為 Project Name。需要注意的是在最後一部分“Properties of features being patched”，一定要選擇帶有具體版本號的 feature。如果這個被應用 Patch 的 Feature 在 Target Platform 上，可以通過“Browse”進行選擇。
圖 2. Feature patch 屬性對 話框
更新 Feature Patch 的版本號，選擇所包含的插件，保存所有修改。
圖 3. Feature Patch 的 feature.xml 編輯窗口
在創建完 Feature patch 工程後，可以將根據要應用補丁的 Feature 的版本號來更新 Feature Patch 的版本號，然後在圖 3 中的 Plug-ins 標簽頁中添加要更新的插件。默認情況下，插件的版本號是 0.0.0，你可以通過選中 “Versions“對話框中的第二項，來顯示具體的版本號。
步驟 4：導出 Feature Patch
右擊 Feature Patch 工程，選擇“Export->Plug-in Development- >Deployable feature”，輸入要保存的位置，如果 Feature patch、feature 或插件中含有 .qualifier 字段，可以通過切換到 Option 標簽頁，勾選“Qualifier replacement“進行替 換，如下圖所示，注意替換字符串對應的 ASCII 碼值應比原有插件版本的 qualifier 部分大。點擊 “Finish”，Feature Patch 就被保存在本地磁盤上了。
圖 4. 導出 Feature Patch 工程對話框
對於基於 Eclipse v3.4.0 的產品來說，還需要為 Patch 產生 P2 元數據。而對於 Eclipse v3.4.1 及以後的版本，由於 P2 的變化，則不需要此步。打開命令提示符，切換到 Eclipse v3.4.0 安裝目錄，運行下面命令即可得 到 P2 元數據。
清單 1. 產生 P2 元數據的命令
eclipsec.exe -application org.eclipse.equinox.p2.metadata.generator.EclipseGenerator
-metadataRepositoryName [PATCH NAME] -metadataRepository file:[PATCH LOCATION]
-artifactRepository file:[PATCH LOCATION] -source [PATCH LOCATION]
-flavor tooling -append - noDefaultIUs -inplace -nosplash
部署與驗證
將生成的 features/plugins 目 錄拷貝到產品環境 Eclipse 所在的目錄，重新啟動應用程序，即完成了 Feature patch 的一次部署。但 對於累積式補丁，考慮到用戶可能已經安裝過舊版本補丁程序，部署流程應能檢測到舊版本的補丁程序並 移除。借助於 Eclipse Link 機制，將補丁程序安裝在 link 文件指向的目錄，能夠比較安全的實現新版 本補丁程序的安裝。在具體實施中，可以通過腳本實現文件的拷貝操作，並調用 Eclipse 運行時參數清 空 Eclipse 緩存，來確保 Eclipse 加載補丁程序中高版本的插件。
補丁是否被正確的安裝可以 通過下面三種方法來檢驗：
通過“Help” -> “About Product Name” ->“Plug-in Details”查看插件的版本號
通過“Help” -> “Software update”查看 Patch 的版本信息
驗證為插件新增加的功能是否存 在。
新版本插件未生效問題診斷
通過上面的步驟，我們已經能夠正確的創建 Feature Patch 並且部署到產品環境。但是當用戶使用產品時，產品功能及 Pug-in details 時 plug-in 版本並 沒有更新，那麼常見的原因為：
插件依賴性未滿足
插件被多個 feature 包含
本文 提供了一種定位原因的思路，首先我們需要了解 Eclipse 啟動機制：Eclipse v3.4 基於 Equinox 框架 構建，Equinox 完全按照 OSGI r4 規范編寫，同時增加了一些自己的擴展，那麼在 Eclipse 啟動的過程 中，主要完成了以下動作，
處理命令行參數
啟動 OSGI 框架，安裝 bundle
對已經 安裝的 bundle，檢查其依賴是否滿足，若滿足則置為 resolved
對已經 resolved 的 bundle，調 用其 activator 的 start 方法，將 bundle 的狀態置為 active 或 lazy-starting
可以通過 – console 參數啟動 OSGI console 來查看 plug-in(bundle) 的狀態，下圖為 OSGI 中的 bundle 狀態轉換圖。若插件版本出現在結果中，且 bundle 狀態為 installed, 那麼說明插件的依賴性未能滿足 (match rule 是否與插件的新版本號一致 )。若新版本的插件不會出現在結果中，則可能是插件被多個 feature 包含，這時就需要。
圖 5. Bundle 狀態圖
