Eclipse 平台
安裝和更新

修訂日期:06/14/01 10:45 AM - 版本:0.12

 
附註:更新管理程式仍在開發中,應該還需要有些更動,才能夠進入穩定狀態。 在這個階段將它提供出來是為了取得早期使用者的意見,但使用者必須瞭解,安裝結構的細節可能會有截然不同的更動。

簡介
實務
套裝慣例
       概念
       元件保存檔
       配置保存檔
       轉換套裝資訊
       安全考量
       套裝 NL
       套裝特定目標支援
      套裝支援交付項目
安裝結構
       完整和參照安裝
       檔案系統對映:完整安裝
       工作區檔案
       檔案系統對映:參照安裝
啟動 Eclipse
更新考量
       更新非平台元件
       更新平台
       更新 JRE
       更新產品檔案
       更新啟動支援
       復原更新失敗
       復原錯誤更新
       安裝清除
       不在管理範圍內的 Eclipse 功能
安裝考量
       新安裝作業
       合併安裝
       平台專用登錄
開發考量
       安裝位置獨立性
       原生執行檔
       並行外掛程式版本支援
       版本移轉

簡介

這份文件概述管理在 Eclipse 平台內之功能遞送的支援。

實務

Eclipse 平台含有一個內建的更新管理程式,用來作為 Eclipse 型功能安裝架構之一部份以及遞送服務更新及功能升級。 以下是 Eclipse 的起始版本所支援的實務:

套裝慣例

概念

外掛程式
Eclipse 開發人員要建置外掛程式。 外掛程式是 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 實作不容許採用巢狀配置。

元件保存檔 (.jar)

依慣例,元件是利用以提供者 Internet 網域名稱為基礎的結構化識別碼來識別的。 例如,eclipse.org 組織可能會產生 org.eclipse.platform 元件。 元件識別碼會作為元件 .jar 名稱的一部份,以及 .jar 結構內(因而也在安裝樹中)的元件目錄名稱。 由於可以同時安裝給定元件的不只一個版本,因此,元件 .jar 的名稱及其目錄名稱也會進行版本識別碼的編碼。 版本識別碼遵循 Eclipse 所定義的外掛程式版本識別碼格式(請參閱 PluginVersionIdentifier 類別的 Javadoc)。 它是由主要、次要和服務元件組成的三部份值識別碼(如 2.4.11)

名稱格式如下:
<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
>

元素和屬性定義如下:

配置保存檔 (.jar)

依慣例,配置是利用以提供者 Internet 網域名稱為基礎的結構化識別碼來識別的。 例如,eclipse.org 組織可能會產生 org.eclipse.sdk 配置。 配置識別碼會作為配置 .jar 名稱的一部份,以及 .jar 結構內(因而也在安裝樹中)的配置目錄名稱。 由於可以同時安裝給定配置的不只一個版本,因此,配置 .jar 的名稱及其目錄名稱也會進行版本識別碼的編碼。 版本識別碼遵循 Eclipse 所定義的外掛程式版本識別碼格式(請參閱 PluginVersionIdentifier 類別的 Javadoc)。 它是由主要、次要和服務元件組成的三部份值識別碼(如 2.4.11)

名稱格式如下:
<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"
>

元素和屬性定義如下:

目前的 Eclipse 實作不容許採用巢狀配置,或指定更複雜的元件規則。

轉換套裝資訊

安裝處理內的許多屬性都是要透過使用者介面來顯示的字串。 為了使轉換更容易進行,這些屬性值都使用專為 plugin.xml 的可轉換屬性而定義的慣例。 開頭為 % 直到第一個空格的字串是作為資源識別碼鍵(不含 %)來處理並在內容檔中進行查閱。 例如,

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 屬性的正確轉換字串。

安全考量

元件和配置 .jar(s) 可利用標準 Java 安全公用程式(如 jarsigner)來進行簽名。 在執行時期,更新管理程式會檢查所要求的 jar 是不是由具公信力的提供者所提供的,以及在簽名之後,jar 內容有沒有修改過。 使用者可以選擇接受不具公信力的 jar。 Eclipse 執行時期會拒絕在簽名後又修改過的 jar。

套裝 NL

NL 檔案套裝在每個支援的語言環境的個別子目錄中。 子目錄可以定義在實際外掛程式目錄(定義在外掛程式的「行內」)中,也可以套裝在個別外掛程式片段中。 不論是哪個情況,Eclipse 執行時期都會提供將基本外掛程式目錄和適當的語言環境檔「接合」到單一邏輯存取結構中的服務(不過,在實體上,會將它們套裝起來)。

將 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 的說明。

套裝特定目標支援

OS 和視窗化系統專用檔案套裝在每個支援目標的個別子目錄中。 子目錄可以定義在實際外掛程式目錄(定義在外掛程式的「行內」)中,也可以套裝在個別外掛程式片段中。 不論是哪個情況,Eclipse 執行時期都會提供將基本外掛程式目錄和適當的目標專用檔「接合」到單一邏輯存取結構中的服務(不過,在實體上,會將它們套裝起來)。

將目標專用檔套裝成外掛程式片段會使安裝結構稍微複雜些。 主要好處是在事實之後,可以將目標專用支援加入基礎中(也就是不必同時出貨)。 它也可讓片段發展基礎具有獨立性(有關服務更新)。

以下是產生的套裝目標專用檔替代安裝結構。

以外掛程式在「行內」套裝目標專用支援

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 支援兩種類型的安裝:
  1. 完整安裝。這是在執行安裝程序之後所產生的檔案系統結構。檔案依照 Eclipse 平台直接執行所需要的方式而放在檔案系統中。Eclipse 功能只能直接執行完整安裝。
  2. 參照安裝。這是位於用來選取可安裝元件及配置之 Eclipse 更新位置的檔案結構

檔案系統對映:完整安裝

完整安裝定義為安裝程序的輸出,不論它是「傳統」安裝或更新管理程式動作,都是如此。 Eclipse 平台可以直接執行完整安裝。

完整 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

內容定義如下:

installation.properties 檔是起始安裝程式所建立的。 安裝好之後,就可以更新應用程式和執行時期內容。 只有 application.ocnfiguration 的版本字尾可以更新(但不是「主要」配置識別碼)。

附註:如這一節所指定,Eclipse 型產品的起始安裝架構也必須安裝反映了正確起始啟動設定的 install.properties 檔。 這個動作失敗的話,就會無法啟動產品。

工作區檔案

在一般的單一使用者配置中,<installation root> 也會含有使用者工作區檔案。 在平台啟動之後,會建立這些檔案。 在多工作區的配置中,平台是藉由指定明確工作區目錄來啟動的。 任何建立為平台執行部份的檔案都會寫入工作區目錄中。 請注意,在多工作區實務中,使用者必須確定隨時只有一個更新管理程式的實例在執行中。 如果多工作區配置事實上代表了多位使用者共用的安裝,共用安裝架構「管理者」應該確定個別使用者只有安裝根目錄的讀取權。

檔案系統對映:參照安裝

參照安裝檔案結構類似於完整安裝。 其中含有:

<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 檔。 不過,請注意,如果檔案存在的話,即使採用直接檔案輸入/輸出存取方式,也會使用它。 在這個方式下,網站管理可以利用檔案來控制要實際外曝哪些配置和元件。 一般而言,當不要下載配置所包含的元件及將它們安裝成個別項目(只透過部份配置來管理)時,這非常有用。 在這個情況下,配置會直接外曝,但元件不會。 元件只能透過外曝的配置來尋找。

啟動 Eclipse

在滿足某些更新考量之前,請務必先瞭解 Eclipse 平台的啟動方式。 其中包括:
  1. 安裝起始目錄目錄含有「產品」啟動指令。這可以是簡單的指令 "Script"(如 .bat),這個 Script 的功能也可由簡單的執行發射台(如 .exe)來執行。不論任何一種情況,啟動指令都會做三件事:
  2. Main 收到傳來的 Eclipse 平台執行檔(執行時期內容)位置及平台要執行之應用程式識別碼(應用程式內容,工作台是 Eclipse 提供的預設應用程式)。Main 會找到平台 boot.jar,且會從中載入平台 BootLoader。它會將應用程式識別碼當作引數來傳遞(還有任何其他啟動引數),而將控制權交給 BootLoader。
  3. BootLoader 會啟動平台基核執行時期。結果會載入和解析外掛程式登錄(配置有執行資格的外掛程式)
  4. BootLoader 會在外掛程式登錄中查閱應用程式名稱(當作引數傳入),如果找到的話,它會啟動應用程式外掛程式,並將控制權交給它。
  5. 啟動的應用程式(如工作台)會適當啟動和呼叫其他外掛程式。
附註:Eclipse 平台的現行版本提供的預設發射台不會實際處理 install.properties 檔(如第 1 和 2 步驟所說明)。它只會找到本身的相關預設歡迎畫面和平台執行時期。

更新考量

更新非平台元件

非平台元件會遞送在平台「上」執行的外掛程式。 更新管理程式只會安裝必要的外掛程式目錄和檔案。 下次啟動平台時,會偵測及處理這些項目。

更新管理程式絕不會更新現有的外掛程式目錄結構。 它只會安裝先前不存在的外掛程式版本。 如果外掛程式目錄已經存在(如包括在某些其他元件(版本)中),就不會重新安裝它。 更新管理程式不會驗證現有的目錄內容是否符合元件 jar 中的目錄內容。 因此,外掛程式版本識別碼必須正確反映在外掛程式目錄名稱中。

更新平台

Eclipse 平台的現行版本不容許利用更新管理程式來更新平台。 平台更新必須透過傳統安裝機制來處理。

更新 JRE

Eclipse 平台的現行版本不容許利用更新管理程式來更新 JRE。 JRE 更新必須透過傳統安裝機制來處理。

更新產品檔

套裝的安裝通常包括最終會放在產品啟動目錄中的許多雜項檔案。 其中包括各種 Readme 檔、歡迎畫面影像、多份授權合約、版次注意事項...等。 這些檔案應該套裝成元件和配置 jar 的一部份(成為特定配置或元件目錄內的任意其他檔案(install.xml 的同層))。 個別檔案和子目錄都可以接受。 在這個方式下,會將這些檔案當作版本化的元件或配置 jar 的一部份來套裝、遞送和安裝。

例如,元件 jar 可能含有

install/
    components/
        com.xyx.etools_1.3.5/
            install.xml
            splash.bmp
            readme.txt
            license.txt
            notes/
                jspedit.txt
                debug.txt

更新啟動支援

Eclipse 平台的現行版本不容許利用更新管理程式來更新發射台。 發射台更新必須透過傳統安裝機制來處理。

復原更新失敗

有兩個實務可供考量。
  1. 控制失敗 - 這些是各種存取、下載、unzip...等由更新管理程式所偵測出的失敗。更新管理程式含有從這些失敗復原的邏輯。
  2. 「非控制」失敗 - 這些是在更新管理程式能夠完成其作業之前,在更新處理過程中的瞬間失敗(如斷電)。這些是在平台啟動時所偵測到的。安裝樹會就最後一個已知的狀態來進行驗證,局部變更會從安裝樹中移除。

復原錯誤更新

更新管理程式會維護安裝架構現行配置狀態的說明。 其中包括「作用中」配置及元件的清單(實際的安裝樹可能含有其他配置和元件版本會因後續更新而實際隱藏起來)。

每次更新管理程式更新和儲存這項資訊(在關閉平台時儲存)時,都會複製狀態資訊,且先前的狀態會依更新的時間順序保留下來。 更新管理程式會維護許多代的狀態(先前狀態的數目是可設定的選項)。 在更新管理程式清除處理程序中,會定期收集(刪除)狀態的舊版本和對應的配置及元件。

狀態的前層次副本提供從不當更新中復原的機制。 在這個實務中,「不當」意指更新管理程式順利下載和套用變更,但這項變更卻產生一些問題。

安裝清除

更新管理程式會定期調整安裝樹的內容。 只有最近幾代更新狀態中的元件和配置參照會保留下來(保留狀態的數目是可設定的選項)。 清除是作為更新管理程式作業的一部份來執行的,不需要明確觸發它。

不在管理範圍內的 Eclipse 功能

除了「正式」安裝的配置和元件之外,Eclipse 平台也能接受直接放在安裝樹中的外掛程式和外掛程式片段,而不需要有任何對應的安裝處理說明它們。 在執行時期,會辨識這些外掛程式和片段,但您不能利用更新管理程式功能來更新或移除它們(它們並「不在管理範圍內的」)。 這個支援主要針對外掛程式開發實務,試圖消除安裝/套裝開發之額外負荷。 傳統的安裝程式不應安裝不在管理範圍內的外掛程式和片段。

安裝考量

從安裝的角度來看,Eclipse 區分了建立新 Eclipse 平台基礎(jre、平台和「主要」應用程式)的安裝架構和只提供(合併)新元件到現有基礎中的安裝架構。

新安裝作業

目前,新平台安裝作業必須利用傳統安裝技術來完成,如 Windows MSI 安裝程式、RPM、IstallShield,或利用簡單的保存機制(如 .zip 檔)來完成。 安裝程式負責確保所產生的檔案結構(安裝完成之後)遵循這份文件中所說明的規格。

安裝程式需要執行下列動作:

您必須有對應的「傳統」解除安裝程式,才能移除「主要」應用程式及其 Eclipse 平台樹。 通常,解除安裝程式負責反轉其安裝程式的動作。 不過,請注意,由於在 Eclipse 更新管理程式的正常使用部份可以變更 Eclipse 安裝樹的內容, 因此,「傳統」解除安裝程式可能不會實際找出原先所安裝的檔案。 有些檔案可能已不存在(為更新管理程式所移除),現在安裝樹可能含有原先所沒有安裝的其他檔案(如套用的更新)。 因此,嚴格依賴安裝日誌的「傳統」解除安裝程式通常無法完全移除應用程式安裝架構。

如果要補償更新管理程式所進行的變更,「傳統」解除安裝程式可以強迫移除在下列 Eclipse 安裝目錄內的所有檔案:

在安裝樹中找到的其他目錄可能含有使用者資料,不應加以移除。

合併安裝

建立好 Eclipse 平台安裝架構之後(請參閱上節),就可以利用 Eclipse 更新管理程式或「傳統」安裝程式將其他元件和配置新增到平台中。 在後一種情況中,安裝程式負責確保所產生的檔案結構(安裝完成之後)遵循這份文件中所說明的規格。

安裝程式需要執行下列動作:

在合併安裝中使用「傳統」的解除安裝程式要特別小心。 一般而言,解除安裝程式絕不應試點移除實際安裝的程式檔案。 原因是原來安裝的檔案可能已經不存在,或所安裝的部份檔案已在正常的 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 平台的唯一方式。

建議您讓 Eclipse 型產品利用 OS 登錄機制來追蹤已安裝的 Eclipse 平台的所有位置。 如此就能在決定要建立新平台安裝架構或將元件合併到現有架構時,進行簡單的查閱。 在沒有提供這類登錄機制的的平台中,會提示使用者明確識別 Eclipse 安裝目錄。

安裝程式通常可用來建立新安裝架構或將元件合併到現有安裝架構中。 建立新安裝架構應該也會更新登錄結構。

在 Windows 中,以 Windows 登錄來達到這個目的。 以下是建議用來識別 Eclipse 平台安裝目錄的登錄錄結構:

eclipse.org/
    platforms/
        <product name>

<product name> 鍵用來識別提供者和/或建立了新 Eclipse 平台安裝架構的主要應用程式。 完整的鍵對映於下列屬性

label = <product name> 鍵的可顯示標籤。在建立時設定區域。
directory = <absolute path>

開發考量

安裝位置獨立性

Eclipse API 可讓負責執行的外掛程式取得指向其安裝目錄的參照。 這是藉由呼叫 IPluginDescriptor.getInstallURL() 來完成的。這個呼叫會傳回 java.net.URL。 負責執行的外掛程式會存取這個 URL 所有必要的相關資源。 URL 通信協定支援會處理必要的重新導向,以導向本端外掛程式目錄、外掛程式快取記憶體、CD(最小安裝)或伺服器。 外掛程式存取資源的一般方式是開啟 URL 的輸入串流,再閱讀該資源的內容。 由於安裝位置是唯讀的,因此,負責執行的外掛程式應該絕不試圖用傳回的 URL 來撰寫。

原生執行檔

Eclipse 外掛程式所用的 Java 原生程式庫不需要任何特殊處理。 它們是作為外掛程式目錄結構的一部份而安裝並由平台類別載入器 (jdk 1.2+) 來載入的。

OS 專用原生元件(如 ActiveX)需要不由 Eclipse 更新管理程式處理的自訂安裝。 自訂安裝程式會在適當的 OS 服務中登錄元件及更新任何標準搜尋路徑。 Eclipse 平台不會為必要的原生元件提供任何自動檢查。 如果要實作必要的檢查/復原邏輯,就必須用到外掛程式碼。 您可以在自訂安裝程式中建立一個「標示元」外掛程式來指示有某些原生元件存在,並讓其他外掛程式指定相依性。 不過,這個方式不是很簡單,也無法成為適當的原生相依性的絕對保證。

並行外掛程式版本支援

Eclipse 平台可讓您同時安裝相同外掛程式的多重版本。 其中包括使用者安裝了兩個 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

容許並行執行及寫入外掛程式狀態或工作資料(請參閱 Plugin.getPluginStateLocation() 和 IProject.getPluginWorkingLocation(IPluginDescriptor))的外掛程式還有另一項考量。 在版本移轉問題之外(請參閱下一節),外掛程式也負責管理從相同外掛程式的多重執行版本並行存取任何共用的外掛程式資源。外掛程式必須使用所選檔案存取 API 的機能來協調並行存取。

版本移轉

由於平台配置的動態性質,外掛程式實作必須知道執行時所可能產生的移轉問題。 Eclipse 型解決方案不像傳統的產品,在使用者啟動應用程式之前,不會實際「集合成形」。

平台提供外掛程式處理每種移轉狀況所能使用的基本機能,不過,最後外掛程式開發人員要負責正確使用這些。

當外掛程式執行時,它們可以將外掛程式專用資訊寫入許多工作位置。您可以利用下列 API 呼叫來取得指向工作位置的參照:

每個外掛程式都負責處理其工作資料的移轉。另外,外掛程式還有兩項基本實務要考量:
  1. 向前移轉 - 已配置外掛程式的新版本,它必須移轉先前的版本所寫入的資料。這是以外掛程式的第 n+1 版能夠讀取相同外掛程式之第 n 版所撰寫之資料為假設。
  2. 向後移轉 - 已移除先前的平台呼叫中所配置的外掛程式版本,變成配置相同外掛程式的更舊的版本(較新的版本原先隱藏了較舊的版本)。這是比較麻煩的實務,因為通常無法假設外掛程式的第 n 版能夠讀取相同外掛程式之第 n+1 版所撰寫的資料。
向前移轉的實務要求新版外掛程式偵測出舊版所撰寫的資料,及讀取、轉換和重寫資料。這可以在第一次啟動新外掛程式版本時執行,也可以在存取工作區時執行。 第一個方法通常比較適合移轉外掛程式「狀態」資料,第二個方法比較適合移轉專案資料。

向後移轉需要外掛程式開發人員進行若干額外工作。基本上,外掛程式的第 n+1 版必須使用至少第 n 版可偵測到的方法來寫入資料。 外掛程式可利用若干可能的技術來處理這個實務。

外掛程式開發人員要負責選擇適當的實作策略。平台不提供任何自動管理外掛程式資料之移轉的特定 API。