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 清单并反映插件目录名中的版本(有关详细信息,参见“并行插件版本支持”)。

插件段
插件段(或就称为段)允许将基本插件的某些方面独立封装。这包括(但可以不限于) 插件、特定于操作系统或特定于窗口系统的代码或供备用用户使用的插件内容 (如随插件一起提供的 SDK 开发者信息)的已转换资源。在运行时,段被逻辑地合并到基本插件中。从封装的角度来看,允许将段与基本插件物理地封装在一起,或独立地封装和处理这些段。例如,允许创建“语言包”或独立于基本功能分发的特定“操作系统包”。

组件
组件通常是包含某些用户功能的一组插件和/或插件段。可将组件作为封装和安装过程的一部分公开给用户,因为组件表示一个功能选择单元。组件还表示一个安装单元(将所有被包含文件一起安装在一个安装树中)。组件具有版本标识符。

组件封装为一个 Java .jar,且包含必须的插件、插件段和组件安装清单(xml 文件)。可由 Eclipse 更新管理器将组件 .jar 置于更新服务器上以供下载和安装,或使用其中一种“传统的”安装程序技术将组件 .jar 用作正式封装过程的输入。将在稍后描述组件 jar 及其安装清单的格式。

配置
配置是用于一组设置了版本的组件的设置了版本的分组机制。例如,可使用它来指定作为产品的特定版本构建和测试了哪个组件配置。

配置封装为 Java .jar,且包含配置安装清单(xml 文件)。清单包含对构成配置的组件的引用,并包含安装和版本更新约束。注意,配置 .jar 不实际包含组件文件(而只包含引用)。

可由 Eclipse 更新管理器将配置 .jar 置于更新服务器上以供下载和安装,或使用其中一种“传统的”安装程序技术将配置 .jar 用作正式封装过程的输入。将在稍后描述配置 jar 及其安装清单的格式。

当前的 Eclipse 实现不允许嵌套配置。

组件归档文件(.jar)

按照惯例,组件是根据供应商因特网域名使用结构化标识符来标识的。例如,组织 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)

按照惯例,配置是根据供应商因特网域名使用结构化标识符来标识的。例如,组织 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 资源绑定命名约定将特性文件命名为 install_<locale>.properties。在组件 .jar 和配置 .jar 中,这些特性文件被放置在它们的相应 install.xml 文件所在的目录中。

访问资源绑定时,代码可选择清单的适当 NL 变体(通过使用查找算法),然后使用以下项创建绑定:

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);

所生成的资源绑定可在 IPluginDescriptor.getResourceString(String,ResourceBundle) 中使用以实际返回清单属性正确的已转换字符串。

安全注意事项

可使用标准 Java 安全性实用程序(例如 jarsigner)来标记组件 .jar 和配置 .jar。在运行时,更新管理器将检查 是否请求的 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 资源,以便功能在没有适当的语言环境树的情况下以合法的方式运作(即,最好是在用户界面中显示缺省字符串而不是资源标识)。

在 Eclipse 平台文档中别的地方描述了用于管理 NL 目录和段的运行时机制、fragment.xml 格式和 API。

封装特定于目标的支持

操作系统文件和特定于窗口系统的文件是在每个受支持目标单独的子目录中封装的。可在实际的插件目录内定义子目录(即定义为与插件“内联”),或者可在单独的插件段中封装这些子目录。在任何一种情况下,Eclipse 运行时都提供了将基本插件目录和适当的指定目标文件“结合”到单个逻辑访问结构的服务(因而将它们物理封装)。

将特定于目标的文件封装为插件段会导致稍为复杂一些的安装结构。主要的益处是在操作之后可将指定目标支持添加到基元中(即不必同时传送)。它还允许段独立于基本插件之外而发展(对于服务更新)。

以下是所产生的用于封装特定于目标的文件的备用安装结构。

封装与插件内联的特定于目标的支持

install/
    plugins/
        <pluginId>_<version>/
            (“插件”文件)
            os/
                <os-name>/
                    (特定于操作系统的文件)
            ws/
                <windowing-system-name>/
                    (特定于窗口系统的文件)

例如:

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>/
                    (特定于操作系统的文件)
            ws/
                <windowing-system-name>/
                    (特定于窗口系统的文件)

例如:

install/
    fragments/
        my.funky.plugin_solaris_1.0.1/
            fragment.xml
            os/
                solaris/
                    libfoo.so
            ws/
                motif/
                    my.jar

用于目录名的目标标识符由 Eclipse 定义(参见 org.eclipse.core.boot.BootLoader 的 Javadoc)。

在 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 和配置 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.configuration 的版本后缀(但不是“主导”配置标识符)。

注意:如本节中所指定的那样,基于 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 或配置 jar 部分地解压缩安装清单(和任何安装资源绑定),然后将整个 jar 复制到结果目录结构(与 install.xml 同级)中,就可创建参考安装。公开 install.xml 将允许更新管理器确定在给定站点中哪些内容可用。一旦进行了选择, 就会下载和安装相应的 .jar。

当由除直接文件 i/o 之外的协议访问参考安装站点时,该站点还必须包含可选的 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

当通过直接文件 i/o(如“文件”URL)引用“站点”时,不需要 install.index 文件。然而,注意,如果该文件存在,则甚至会在直接文件 i/o 访问的情况下使用它。通过这种方法,可由站点管理使用该文件来控制实际公开哪些配置和组件。通常,当不想将包含在配置中的组件作为独立项(即,仅通过某些配置进行管理)下载和安装时,这是很有用的。在这种情况下,将直接公开配置,但不公开组件。将仅通过公开的配置定位组件。

启动 Eclipse

在了解某些更新注意事项之前,了解如何启动 Eclipse 平台是很重要的。这涉及下列内容:
  1. 安装根目录包含“产品”启动命令。启动命令可以是简单的命令“脚本”(例如 .bat),或者此脚本的功能可由简单的可执行启动板(例如 .exe)执行。在以上任何一种情况下,启动命令都进行三项操作
  2. 将 eclipse 平台可执行文件的位置(运行时特性)以及平台要执行的应用程序的标识符(应用程序特性,工作台是 Eclipse 提供的缺省应用程序)传送给 Main。Main 定位平台 boot.jar 并从其装入平台 BootLoader。它将控制权交给将应用程序标识符作为自变量(以及任何其他启动自变量)传送的 BootLoader。
  3. BootLoader 导致平台核心运行时启动。这将导致装入和解析插件注册表(配置将可供执行的插件)。
  4. BootLoader 在插件注册表中查找应用程序名(作为自变量传送),如果找到,则激活应用程序插件并将控制权交给它。
  5. 所启动的应用程序(如工作台)将激活并在适当时调用其他插件
注意:随 Eclipse 平台的当前版本一起提供的缺省启动板并不处理 install.properties 文件(如上面的步骤 1 和步骤 2 所述)。它只定位缺省闪屏和与它本身相关的平台运行时。

更新注意事项

更新非平台组件

非平台组件交付在平台“顶部”执行的插件。更新管理器只安装必需的插件目录和文件。下一次平台启动时,将会检测和处理这些内容。

更新管理器从不更新现有的插件目录结构。它只安装先前不存在的插件版本。如果插件目录已存在(例如:包括在另外某个(版本的)组件中),就不会再次安装它。更新管理器不验证现有目录内容是否与组件 jar 中的目录内容相匹配。因此,必须在插件目录名中正确反映插件版本标识符。

更新平台

当前的 Eclipse 平台版本不允许使用更新管理器更新平台本身。需要通过传统安装机制来处理平台更新。

更新 JRE

当前的 Eclipse 平台版本不允许使用更新管理器更新 JRE。需要通过传统安装机制来处理 JRE 更新。

更新产品文件

已封装的安装通常包括许多最后放置于产品启动目录中的各种文件。这包括各种自述文件、闪动画面、许可证协议副本、发行说明等等。应将这些文件作为组件 jar 和配置 jar 的一部分封装(作为特定配置或组件目录内的任意附加文件(与 install.xml 同级))。允许封装个别文件和子目录。通过这种方法,将这些文件作为设置了版本的组件 jar 或配置 jar 封装、交付和安装。

例如,组件 jar 可能包含

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

更新启动支持

当前 Eclipse 平台版本不允许使用更新管理器更新启动板(.exe 和 startup.jar)。需要通过传统安装机制处理启动板更新。

从更新故障中恢复

要考虑两个方案。
  1. 受控的故障 — 即更新管理器检测到的各种访问、下载、解压缩等故障。更新管理器包含从这些故障中恢复的逻辑。
  2. “不受控”故障 — 即在更新管理器有希望完成其操作之前在更新处理当中出现的突发故障(例如:掉电)。在平台启动时检测这些故障。对上一已知状态验证安装树且将任何部分更改从安装树中除去。

从错误更新中恢复

更新管理器维护安装的当前配置状态的描述。这包括“活动”配置和组件的列表 (实际安装树可能包含因后续更新而有效地隐藏附加配置和组件版本)。

每次更新管理器更新和保存此信息(保存在平台关闭时完成)时,就克隆此状态信息,且先前的状态就保存为按时间顺序排列的更新序列。更新管理器维护若干个状态生成(先前状态的数目是可设置的)。会定期收集(删除)旧状态版本及相应的配置和组件作为更新管理器清理处理的一部分。

状态的后备级副本提供了用于从错误更新中恢复的机制。在此方案中,“错误”表示更新管理器成功下载及应用了更改,但该更改导致发生问题。

安装清理

更新管理器周期性地调整安装树的内容。仅保留更新状态的若干最新生成(保留的状态数目是可设置的)中的组件和配置引用。将清理作为更新管理器操作的一部分执行,不必显式触发。

不受管 Eclipse 功能

除“正式”安装的配置和组件外,Eclipse 平台还容许直接放置到安装树中而没有任何相应安装清单描述的插件和插件段。在运行时会识别这些插件和插件段,但不能使用更新管理器功能更新或除去它们(即“不受管理的”)。这种支持特别适合试图排除安装/封装开发的插件开发方案。传统的安装程序不应安装不受管理的插件和插件段。

安装注意事项

从安装的角度来看,Eclipse 在建立新的 Eclipse 平台基本内容(jre、平台和“主导”应用程序)的安装与只是将新组件添加(合并)到现有基本内容中的安装有一定区别。

新安装

目前,必须使用传统安装技术(如 Windows MSI 安装程序、RPM、InstallShield 或简单压缩机制(例如 .zip 文件)进行新的平台安装。安装程序负责确保所产生的结果文件结构(在安装完成之后)遵循此文档中描述的规范。

安装程序需要执行下列操作:

必须提供相应的“传统”卸载程序以除去“主导”应用程序及其 Eclipse 平台树。通常,卸载程序负责撤销其安装程序的操作。然而,要注意,因为 Eclipse 安装树的内容可作为使用 Eclipse 更新管理器的一个普通部分而更改,所以“传统”卸载程序实际上可能发现不了原来安装的文件。某些文件可能不再存在(已由更新管理器除去),而且现在安装树可能包含其他不是原来安装的文件(例如:应用的更新)。因此,严格依赖于安装日志的“传统”卸载程序一般不能完全除去应用程序安装。

为了补充更新管理器所做的更改,“传统”卸载程序可强制除去下列 Eclipse 安装目录内的所有文件:

安装树中的其他目录可能包含用户数据,不应将它们除去。

合并安装

一旦建立了 Eclipse 平台安装(参见前一节),就可使用 Eclipse 更新管理器或“传统”安装程序将附加的组件和配置添加到平台中。以后,安装程序就负责确保所产生的文件结构(在安装完成之后)遵循此文档中描述的规范。

安装程序需要执行下列操作:

将“传统”卸载程序用于合并安装必须特别小心。通常,卸载程序决不应试图除去实际安装的程序文件。原因是原来安装的文件可能不再存在,或所安装的某些文件已作为 Eclipse 操作的一个普通部分而进行了更新。因此,试图直接除去原来安装的文件可能导致的最好情况是系统仍正常工作或未受到任何影响,而最坏情况则可能会导致除去所安装支持的某一部分(导致下次启动应用程序时发生不可预期的故障)。共享组件或插件的情况就更为严重。仅当在保证未更新过配置或组件且不存在共享的情况下,才可直接除去这些文件。

当使用不允许对卸载过程进行以上控制(即:禁止除去所安装的文件)的安装程序技术时,应小心进行。Linux 上的 RPM 就是这样一个示例。在这些情况下,应避免对合并安装使用特定安装程序技术,或者决不应执行结果卸载。

“传统”卸载程序可通过使用合并的安装“根目录”文件来支持安全除去所安装的功能。这些文件是作为合并安装的一部分安装(可选)的,并充当相应配置和组件的锚点。Eclipse 平台在启动期间检测除去“根目录”文件的情况,并安全除去列示的配置和组件。

注意:与配置和组件文件本身不同,“根目录”文件不遵从更新管理器进行的更改。因此,“传统”卸载程序可因这些情况而在安装之后保留下来。

安装之后,将“根目录”文件置于 Eclipse 安装树内的 install/info/ 目录中(与 install/configurations 和 install/components 目录同级)。文件使用下列命名约定:

<merged-installation-identifier>.install

Eclipse 平台不指定标识符的格式(不作任何形式的解释)。要使发生命名冲突的可能性降至最小, 强烈建议标识符使用基于供应商因特网域名(例如 com.xyz.toolpack.install)的命名约定。

“根目录”文件的内容使用 Java 特性文件格式,并包含以下内容:

configurations=[<configId>_<version> [, <configId>_<version>]* ]
components=[<compId>_<version> [,<compId>_<version>]* ]

其中
[]为可选元素
* 为重复的分组

(在纯英文中,所有特性都是以逗号分隔的(相应的以版本为后缀的标识符的)列表)

特定于平台的注册

注意:本节描述建议的“最佳实践”。但对于正确执行 Eclipse 平台来说,它不是必需的。

建议基于 Eclipse 的产品使用操作系统注册机制以跟踪所有安装的 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+)装入。

特定于操作系统的本机组件(如 ActiveX)需要不由 Eclipse 更新管理器处理的定制安装。定制安装程序向适当的操作系统服务注册组件并更新任何标准搜索路径。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 所写的数据。
向前迁移方案要求新插件版本检测由前一版本所写的数据,并读取、转换和重写该数据。第一次激活新插件版本(Plugin.startup())或访问工作区时就可执行这些操作。通常,第一种方法更适合于迁移插件“状态”数据,而第二种方法更适合于迁移项目数据。

向后迁移要求进行一些属于插件开发者工作范围的附加工作。实质上,插件的版本 n+1 需要以这样一种方法写数据:版本 n 至少可检测到此情况。有若干种可能的插件可用来处理此方案的技术。

插件开发者负责选择适当的实现策略。平台不提供用于自动管理插件数据迁移的任何特定 API。