附註:更新管理程式仍在開發中,應該還需要有些更動,才能夠進入穩定狀態。 在這個階段將它提供出來是為了取得早期使用者的意見,但使用者必須瞭解,安裝結構的細節可能會有截然不同的更動。 |
簡介
實務
套裝慣例
概念
元件保存檔
配置保存檔
轉換套裝資訊
安全考量
套裝 NL
套裝特定目標支援
套裝支援交付項目
安裝結構
完整和參照安裝
檔案系統對映:完整安裝
工作區檔案
檔案系統對映:參照安裝
啟動 Eclipse
更新考量
更新非平台元件
更新平台
更新 JRE
更新產品檔案
更新啟動支援
復原更新失敗
復原錯誤更新
安裝清除
不在管理範圍內的 Eclipse 功能
安裝考量
新安裝作業
合併安裝
平台專用登錄
開發考量
安裝位置獨立性
原生執行檔
並行外掛程式版本支援
版本移轉
當外掛程式在開發中(也就是經常會變更),它們的內部檔案結構會反映開發人員方便使用的狀態。 這通常會相依於所用的特定開發工具。 不過,開發人員通常會設定外掛程式來從外曝的 .class 檔所在的目錄樹中執行,而不會從 .jar 執行(需要建立 .jar 的額外步驟,我們都知道開發人員本來就會有額外的步驟)。 另外,在這個階段中,開發人員不需要特別注意外掛程式的版本化資訊,因為外掛程式會持續變更。
不過,當外掛程式準備好要套裝之後, 就必須將它轉換成套裝和安裝所適用的格式。 它通常代表建立執行時期 .jar 及移除任何開發時期檔案(原始的、外曝的 .class 檔...等)。 它也表示以正式的外掛程式版本來更新 plugin.xml 處理以及反映外掛程式目錄名稱中的版本(請參閱「並行外掛程式版本支援」,以取得詳細資料)。
外掛程式片段
外掛程式片段(或簡稱「片段」)可讓您獨立套裝基本外掛程式的某些方面。
其中包括(但不限於)外掛程式、OS 專用或視窗化系統專用程式碼的轉換資源,或鎖定替代使用者
的外掛程式內容(如外掛程式所提供的 SDK 開發人員資訊)。
在執行時期,片段會邏輯地合併到基本外掛程式中。
從套裝的角度來看,在實體上,它們可與基本外掛程式套裝在一起,也可以個別地套裝和服務。
例如,這讓您建立「語言封包」或獨立於基本函數分散之外的特定「OS 封包」。
元件
元件通常是一群交付某些使用者函數的外掛程式和/或外掛程式片段。
元件可以作為套裝和安裝程序的一部份來外曝在使用者面前,因為它們代表一個函數選取單元。
元件也代表安裝單元(所有包含的檔案都安裝到同一安裝樹中)。
元件含有版本識別碼。
元件會套裝成 Java .jar,其中含有必要的外掛程式、外掛程式片段和元件安裝架構處理(xml 檔)。 元件 .jar 可以放在更新伺服器中,讓 Eclipse 更新管理程式進行下載和安裝,在使用「傳統」安裝程式技術的正式套裝程序中,也可以利用它們來作為輸入。 稍後會說明元件 jar 的格式及其安裝處理。
配置
配置是可供一組已版本化的元件使用的版本化分組機制。
例如,它可用來指定什麼元件配置是作為特定產品版本來一起建置和測試。
配置會套裝成其中含有配置安裝處理(XML 檔)的 Java .jar。 處理含有組成配置的元件參照,以及安裝和版本更新限制。 請注意,配置 .jar 不實際含有元件檔(只有參照)。
配置 .jar 可以放在更新伺服器中,讓 Eclipse 更新管理程式進行下載和安裝,在使用「傳統」安裝程式技術的正式套裝程序中,也可以利用它們來作為輸入。 稍後會說明配置 jar 的格式及其安裝處理。
目前的 Eclipse 實作不容許採用巢狀配置。
名稱格式如下:
<componentId>_<version>
例如,
org.eclipse.platform_1.0.3.jar
com.ibm.tools.jspeditor_3.1.0\install.xml
元件 jar 有下列內部路徑結構:
install/
components/
<componentId>_<version>/
install.xml
(其他選用檔案)請參閱「轉換套裝資訊」
plugins/
<pluginId>_<pluginVersion>/
plugin.xml
(其他外掛程式檔)
fragments/
<fragmentId>_<fragmentVersion>/
fragment.xml
(其他片段檔,可能也包括 plugin.xml)
.jar 含有正好一個 install/components/ 路徑,其中有正好一個 install.xml 檔。 它含有它們的相對目錄中的零或多個外掛程式(含版本限定元)。 它含有它們的相對目錄中的零或多個外掛程式片段(含版本限定元)。 它也含有 Java jar 公用程式所產生的 meta-inf/ 目錄。
元件 install.xml 格式由下列 dtd 定義:
<?xml encoding="US-ASCII"?>
<!ELEMENT component (description?, url?, plugin*, fragment*)>
<!ATTLIST component
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
provider-name CDATA #IMPLIED
>
<!ELEMENT description (#PCDATA)>
<!ELEMENT url (update*, discovery*)>
<!ELEMENT update EMPTY>
<!ATTLIST update
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT discovery EMPTY>
<!ATTLIST discovery
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT plugin EMPTY>
<!ATTLIST plugin
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
>
<!ELEMENT fragment EMPTY>
<!ATTLIST fragment
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
>
元素和屬性定義如下:
名稱格式如下:
<configurationId>_<version>
例如,
org.eclipse.sdk_1.1.5.jar
com.ibm.wsa_1.0.1\install.xml
配置 jar 有下列內部路徑結構:
install/
configurations/
<configurationId>_<version>/
install.xml
(其他選用檔案)請參閱「轉換套裝資訊」
(「產品」檔案)請參閱「啟動 Eclipse」
.jar 含有正好一個 install/configurations/ 路徑,其中有正好一個 install.xml 檔。 它也含有 Java jar 公用程式所產生的 meta-inf/ 目錄。
配置 install.xml 格式由下列 dtd 定義:
<?xml encoding="US-ASCII"?>
<!ELEMENT configuration (description?, url?, component*)>
<!ATTLIST configuration
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
provider-name CDATA #IMPLIED
application CDATA #IMPLIED
>
<!ELEMENT description (#PCDATA)>
<!ELEMENT url (update*, discovery*)>
<!ELEMENT update EMPTY>
<!ATTLIST update
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT discovery EMPTY>
<!ATTLIST discovery
url CDATA #REQUIRED
label CDATA #IMPLIED
>
<!ELEMENT component EMPTY>
<!ATTLIST component
label CDATA #IMPLIED
id CDATA #REQUIRED
version CDATA #REQUIRED
allowUpgrade (true | false) "false"
optional (true | false) "false"
>
元素和屬性定義如下:
label="%cfg Eclipse SDK for Linux"
結果會在含 "cfg" 鍵的正確內容檔中進行資源查閱。 如果沒有提供內容檔或找不到鍵,就會使用預設字串值(在 %key 之後)。
內容檔的名稱為使用「Java 資源 Bundle」命名慣例的 install_<locale>.properties。 在元件和配置 .jar 內,它們放在對應的 install.xml 檔的相同目錄中。
當存取「資源 Bundle」時,程式碼可以選取處理的適當 NL 變體(實作查閱演算法),再利用下列程式碼來建立 Bundle:
ResourceBundle b;
b = new PropertyResourceBundle(properties.openStream());
另外,程式碼也可以依照下列方式,使用基本 Java 支援來尋找處理的正確 NL 變體:
ResourceBundle b;
ClassLoader l;
l = new URLClassLoader(new URL[] {<targetDirectoryURL>}, null);
b = ResourceBundle.getBundle("install",Locale.getDefault(),l);
產生的資源 Bundle 可用在 IPluginDescriptor.getResourceString(String,ResourceBundle) 中,以實際傳回 manifest 屬性的正確轉換字串。
將 NL 檔套裝成外掛程式片段會使安裝結構稍微複雜些。 主要好處是在事實之後(也就是不必同時出貨),可以將 NL 內容加入基礎中。 它也可讓片段發展基礎具有獨立性(有關服務更新)。
以下是產生的套裝 NL 替代安裝結構。
以外掛程式在「行內」套裝 NL
install/
plugins/
<pluginId>_<version>/
(「外掛程式」檔)
nl/
<locale>/
(NL 檔)
例如:
install/
plugins/
my.funky.plugin_1.0.1/
plugin.xml
my.jar ... 含有類別和預設資源
nl/
de_DE/
my.jar ... 含有轉換的差異
將 NL 套裝成外掛程式片段
install/
fragments/
<fragmentId>_<version>/
fragment.xml
nl/
<locale>/
(NL 檔)
例如:
install/
fragments/
my.funky.plugin_german_1.0.1/
fragment.xml
nl/
de_DE/
my.jar ... 含有轉換的差異
語言環境目錄名稱遵循標準 Java 語言環境命名慣例。
請注意,基本外掛程式內容通常應該固定包括預設 NL 資源,因此,在沒有適當的語言環境樹時,函數仍會有適當的行為(也就是說,在 UI 中,顯示預設字串比顯示資源 ID 恰當)。
在 Eclipse 平台文件的它處,另有執行時期機制、fragment.xml 格式及管理 NL 目錄和片段的 API 的說明。
將目標專用檔套裝成外掛程式片段會使安裝結構稍微複雜些。 主要好處是在事實之後,可以將目標專用支援加入基礎中(也就是不必同時出貨)。 它也可讓片段發展基礎具有獨立性(有關服務更新)。
以下是產生的套裝目標專用檔替代安裝結構。
以外掛程式在「行內」套裝目標專用支援
install/
plugins/
<pluginId>_<version>/
(「外掛程式」檔)
os/
<os-name>/
(OS 專用檔)
ws/
<windowing-system-name>/
(WS 專用檔)
例如:
install/
plugins/
my.funky.plugin_1.0.1/
plugin.xml
my.jar
os/
solaris/
libfoo.so
ws/
motif/
my.jar
將目標特定支援套裝成外掛程式片段
install/
fragments/
<fragmentId>_<version>/
fragment.xml
os/
<os-name>/
(OS 專用檔)
ws/
<windowing-system-name>/
(WS 專用檔)
例如:
install/
fragments/
my.funky.plugin_solaris_1.0.1/
fragment.xml
os/
solaris/
libfoo.so
ws/
motif/
my.jar
目錄名稱所用的目標識別碼是 Eclipse 所定義的(請參閱 Javadoc,以瞭解 org.eclipse.core.boot.BootLoader)。
在 Eclipse 平台文件的它處,另有執行時期機制、fragment.xml 格式及管理目標專用目錄和片段的 API 的說明。
完整 Eclipse 安裝含有下列檔案結構:
<installation root>/
install/
install.properties
components/
<componentId>_<version>/
install.xml
install_<locale>.properties(選用)
configurations/
<configurationId>_<version>/
install.xml
install_<locale>.properties(選用)
(其他「產品」檔)(選用)
plugins/
<pluginId>_<version>/
plugin.xml
(其他外掛程式檔)
fragments/
<fragmentId>_<fragmentVersion>/
fragment.xml
(其他片段檔,可能也包括 plugin.xml)
目錄和檔案的定義在指定給元件和配置 jar 之前。
install.properties 檔含有可配置的啟動內容。它反映平台及安裝的應用程式的現行啟動設定。 請參閱「啟動 Eclipse」一節,以取得確實用法的說明。這個檔案開始時是安裝成新安裝架構的一部份。 後來只有每次更新 Eclipse 安裝架構時,更新管理程式才會更新它。 如果採樣式不符合原始安裝架構的其他方式更新過檔案,就會回復為上一次有效的狀態。
檔案採 Java 內容檔的格式,其中含有下列內容:
application=<applicationId>
application.configuration=<configurationId>_<version>
runtime=<pluginId>_<version>
例如,
application=
application.configuration=com.ibm.wsa_1.0.3
runtime=org.eclipse.core.boot_1.1.4
內容定義如下:
附註:如這一節所指定,Eclipse 型產品的起始安裝架構也必須安裝反映了正確起始啟動設定的 install.properties 檔。 這個動作失敗的話,就會無法啟動產品。
<installation root>/
install/
components/
install.index(選用)
<componentId>_<version>/
install.xml
install_<locale>.properties(選用)
<componentId>_<version>.jar
configurations/
install.index(選用)
<configurationId>_<version>/
install.xml
install_<locale>.properties(選用)
<configurationId>_<version>.jar
參照安裝可以簡單地藉由從元件或配置 jar 中局部 unzip 安裝處理(及任何安裝資源 bundle)再將整個 jar 複製到出現的目錄結構中(作為 install.xml 的同層)來建立。 外曝 install.xml 可讓更新管理程式判斷在給定的網站中能夠使用什麼。 選好之後,就會下載和安裝對應的 .jar。
當利用直接檔案輸入/輸出以外的通信協定來存取參照安裝網站時,網站也必須含有選用的 install.index(在 components/ 和 configurations/ 目錄中)。 這個檔案是簡單的目錄。它將實際子目錄名稱列在個別行中。
例如:
<installation root>/
install/
components/
install.index
org.eclipse.platform_1.0.1/
org.eclipse.jdt_2.9.5/
org.eclipse.pde_1.0.4/
install.index 檔會含有:
org.eclipse.platform_1.0.1
org.eclipse.jdt_2.9.5
org.eclipse.pde_1.0.4
當參照透過直接檔案輸入/輸出(採用 "file" URL)來參照「網站」時,不需要 install.index 檔。 不過,請注意,如果檔案存在的話,即使採用直接檔案輸入/輸出存取方式,也會使用它。 在這個方式下,網站管理可以利用檔案來控制要實際外曝哪些配置和元件。 一般而言,當不要下載配置所包含的元件及將它們安裝成個別項目(只透過部份配置來管理)時,這非常有用。 在這個情況下,配置會直接外曝,但元件不會。 元件只能透過外曝的配置來尋找。
更新管理程式絕不會更新現有的外掛程式目錄結構。 它只會安裝先前不存在的外掛程式版本。 如果外掛程式目錄已經存在(如包括在某些其他元件(版本)中),就不會重新安裝它。 更新管理程式不會驗證現有的目錄內容是否符合元件 jar 中的目錄內容。 因此,外掛程式版本識別碼必須正確反映在外掛程式目錄名稱中。
例如,元件 jar 可能含有
install/
components/
com.xyx.etools_1.3.5/
install.xml
splash.bmp
readme.txt
license.txt
notes/
jspedit.txt
debug.txt
每次更新管理程式更新和儲存這項資訊(在關閉平台時儲存)時,都會複製狀態資訊,且先前的狀態會依更新的時間順序保留下來。 更新管理程式會維護許多代的狀態(先前狀態的數目是可設定的選項)。 在更新管理程式清除處理程序中,會定期收集(刪除)狀態的舊版本和對應的配置及元件。
狀態的前層次副本提供從不當更新中復原的機制。 在這個實務中,「不當」意指更新管理程式順利下載和套用變更,但這項變更卻產生一些問題。
安裝程式需要執行下列動作:
如果要補償更新管理程式所進行的變更,「傳統」解除安裝程式可以強迫移除在下列 Eclipse 安裝目錄內的所有檔案:
安裝程式需要執行下列動作:
當使用不容許上述解除安裝程序之控制的安裝程式技術(亦即:抑止移除已安裝的檔案)時,要特別小心。Linux 中的 RPM 就是一個例子。 在這些情況下,合併安裝應該避免特定的安裝程式技術,否則,應該絕不執行所產生的解除安裝作業。
「傳統」解除安裝程式可支援利用合併安裝「根」檔案來安全移除所安裝的函數。 這些都可選擇性地安裝成合併安裝架構的一部份,它們的用途是作為對應配置和元件的錨點。 在啟動期間,Eclipse 平台會偵測出有沒有移除「根」檔案,且會安全移除列出的配置和元件。
附註:「根」檔案不像配置和元件檔案,更新管理程式不會改變它。 因此,「傳統」解除安裝程式在安裝之後,可依賴這些而保留不動。
安裝之後,「根」檔案放在 Eclipse 安裝樹內的 install/info/ 目錄中(在 install/configurations 和 install/components 目錄的同層)。 檔案會使用下列命名慣例:
<merged-installation-identifier>.install
Eclipse 平台不會指定識別碼的格式(不會以任何方式來解譯)。 如果要將命名衝突的機會減到最少,強力建議您讓識別碼使用以提供者 Internet 網域名稱為基礎的命名慣例(如 com.xyz.toolpack.install)。
「根」檔案的內容會使用 Java 內容檔格式,其中含有:
configurations=[<configId>_<version> [, <configId>_<version>]*
]
components=[<compId>_<version> [,<compId>_<version>]*
]
其中
[]optional element
* 重複群組
(在純英文中,兩個內容都是對應的附加版本字尾識別碼的逗號分隔清單)
建議您讓 Eclipse 型產品利用 OS 登錄機制來追蹤已安裝的 Eclipse 平台的所有位置。 如此就能在決定要建立新平台安裝架構或將元件合併到現有架構時,進行簡單的查閱。 在沒有提供這類登錄機制的的平台中,會提示使用者明確識別 Eclipse 安裝目錄。
安裝程式通常可用來建立新安裝架構或將元件合併到現有安裝架構中。 建立新安裝架構應該也會更新登錄結構。
在 Windows 中,以 Windows 登錄來達到這個目的。 以下是建議用來識別 Eclipse 平台安裝目錄的登錄錄結構:
eclipse.org/
platforms/
<product name>
<product name> 鍵用來識別提供者和/或建立了新 Eclipse 平台安裝架構的主要應用程式。 完整的鍵對映於下列屬性
label = <product name> 鍵的可顯示標籤。在建立時設定區域。
directory = <absolute path>
OS 專用原生元件(如 ActiveX)需要不由 Eclipse 更新管理程式處理的自訂安裝。 自訂安裝程式會在適當的 OS 服務中登錄元件及更新任何標準搜尋路徑。 Eclipse 平台不會為必要的原生元件提供任何自動檢查。 如果要實作必要的檢查/復原邏輯,就必須用到外掛程式碼。 您可以在自訂安裝程式中建立一個「標示元」外掛程式來指示有某些原生元件存在,並讓其他外掛程式指定相依性。 不過,這個方式不是很簡單,也無法成為適當的原生相依性的絕對保證。
Eclipse 平台也容許並行配置和執行相同外掛程式的多重版本。 這是專為了含有共用執行程式庫的外掛程式而設計的。 共用執行時期的給定使用者可以指定相依於外掛程式的特定版本。 這類外掛程式必須宣告它的執行程式庫(在 plugin.xml 的 <runtime> 區段),且一定不能宣告 任何要給平台的構成要責(特別是不能宣告延伸點和/或提供延伸項目)。
為了提供這項支援,Eclipse 平台定義了專用來識別外掛程式的設計、在檔案系統內命名外掛程式目錄的慣例,以及一組配置和執行啟動平台時所找到的外掛程式的規則。
外掛程式是用類似 Java 套件名稱的結構化字串和多重十進位版本識別碼的組合來識別的。 這個版本識別碼由指出不相容產生項的主要元件及指出相容的外掛程式發展的次要元件組成。
外掛程式 | 版本 | 建議的目錄名稱 |
org.eclipse.ui | 1.3.17 | org.eclipse.ui_1.3.17 |
edu.xyz.tools | 1.0.1 | edu.xyz.tools_1.0.1 |
平台提供一個用來處理版本識別碼的 API
平台提供外掛程式處理每種移轉狀況所能使用的基本機能,不過,最後外掛程式開發人員要負責正確使用這些。
當外掛程式執行時,它們可以將外掛程式專用資訊寫入許多工作位置。您可以利用下列 API 呼叫來取得指向工作位置的參照:
向後移轉需要外掛程式開發人員進行若干額外工作。基本上,外掛程式的第 n+1 版必須使用至少第 n 版可偵測到的方法來寫入資料。 外掛程式可利用若干可能的技術來處理這個實務。