驾驭 Eclipse 功能部件：如何使用 Eclipse 功能部件来定制 Eclipse 行为

构建一个插件是很有趣的：您开始编写代码并创建您想要的工具。把插件拷贝到 Eclipse 或一个基于 Eclipse 的产品中的 \plupgins 目录下，这个插件在 Eclipse 运行期环境中就可以使用了。当再一次使用 Eclipse 的时候，插件将被找到，而且经过平台的启动处理，它在运行期配置中将是可用的。

但是谁知道或者关心您的插件加入了进来？用户可以明白您提供的是什么工具吗？他们可以通过 Eclipse 来禁用、修补或者管理您的组件吗？答案显然是否定的。插件本身仅仅是一个插件，而不是与 Eclipse 平台完全集成的组件。

功能部件包装插件
如果没有功能部件，插件是难以驾驭的，通俗地说，不属于功能部件的插件是未被管理的插件。Eclipse 平台的启动过程包括一个配置的步骤。如果一个新的插件被拷贝到 \plugins 目录，或者以其他方式使 Eclipse 在启动的时候可以找到，配置过程会发现它，但只是通过将新插件的 splash 图标闪烁两次来通知您。Eclipse 之所以会发现新的插件，是因为存贮在 \.metadate\.config\platform 中的当前工作区的配置校验和发生了变化；由于您没有向平台提供一个可以引导用户做出配置修改的功能部件，Eclipse 也只能是通过 splash-flash来提示这一变化。将您的插件打包为一个（或两个）功能部件，您将获得如下好处：

在 Eclipse 的配置过程中列出您的组件（在 feature.xml 文件中）所要求的先决条件

使您的组件可以作为 Eclipse 配置的活动部分来管理

创建标记信息，让使用那些使用运行期环境的用户可以识别您的组件，并通过一个欢迎页面来告知用户您的功能部件所提供的功能（在关联到您的功能部件的 welcome.xml 文件中）

用 Eclipse 更新管理器可以对您的组件进行修改

不要等到您的插件开发完成后再打包为功能部件。反映在功能部件定义中的设计结果会影响您如何构建您的插件。例如，大多数的 Eclipse 组件都有 UI 功能部件和核心（不是 UI）功能部件。如果您的插件没有按这种方法进行划分，您可能会马上考虑重新设计它们。功能部件也可以用来自动编译处理被引用的插件。

主要功能部件标识一个产品（但是您有控制权）

虽然功能部件很多，但是当您启动 Eclipse 的时候，只有一个功能部件处于控制之下。这个主要功能部件决定了产品的标识和其他运行期行为，包括确定名字和与运行期平台相关联的图示，以及对所有插件默认属性值的重新定义选项。在后面的 定义您自己的全局属性中可以看到，这个功能强大的选项使您可以定制您自己的 Eclipse 设置。

功能部件构建插件（如果您允许它们）

插件开发环境（PDE）可以自动完成为完整的运行期环境准备功能部件和插件的大部分工作。参见 Eclipse.org 中文章的讨论 "PDE 生成插件"。这些基本的步骤在The Java Developer's Guide to Eclipse中也曾作为一个练习涉及到，遵循那个练习您可以构建并标识您已有的插件。可以说如果您有一个功能部件，并且了解 PDE 如何帮助您构建插件和功能部件，您就可以构建一个功能部件，然后让它去同时构建所有相关的插件。构建控制策略（bin.excludes 与 bin.includes）将在后面的 使用 PDE 构建功能部件的策略中讨论。这些策略是对 Eclipse.org 文章以及The Java Developer's Guide to Eclipse一书的补充。

平台配置管理

理解功能部件所需要条件有助于理解它们如何对活动配置中可用的内容进行管理。

启动过程

如果是一个刚解压缩的 Eclipse 平台，那么当您启动 eclipse.exe 的时候将会发生：

安装可能已经完成

如果一个工作区已经存在，那么会有一个 .metadata\.config\platform.cfg 配置文件。

如果您是以常规方式安装 Eclipse，您得运行 eclipse -initialize 命令来生成一个默认的初始化配置文件，放置在 eclipse\.config 目录下。这样当 Eclipse 以新的工作区启动时不再出现 Completing the install的图示。

找到 Java 运行期环境（JRE）。默认情况下，Eclipse 首先查找 exlipse\jre 子目录。如果没有找到，Eclipse 将查找在系统中注册的 Java 运行期环境。
注意：-vm dir-location 参数可以用到指定其他的 JRE。

配置被作为新的工作区的一部分创建出来。新的工作区通常没有任何的配置，所以您会在真正的 splash 图标之前看到一个图标，通知您安装设置完成。

处理那些注册到 Eclipse 的功能部件和插件，并创建在后面将会用于检测变化的校验和。这些功能部件和插件或者位于当前的 eclipse\features 目录和 eclipse\plugins 目录下，或者位于由链接文件指定的 eclipse\... 目录结构中。

一旦 Eclipse 启动，活动配置定义将包含在 .metadata\.config\platform.cfg 文件中。

链接文件如何扩展一个 Eclipse 安装设置

如果您已经使用了一段时间的 Eclipse 或者在您的配置中添加了哪怕只是一个新的插件，您肯定知道 Eclipse 是到 eclipse\features 目录和 eclipse\plugins 目录下去查找功能部件和插件的。不过您是否知道，Eclipse 也会到文件系统的其他位置去查找功能部件和插件？如果在 eclipse\links 目录下存在格式正确的链接文件，那么这些文件会被处理，相关联的功能部件和插件（包括没有相关功能部件的插件）在运行期配置中都会是可用的。

一个链接文件只是一个命名为 id.link 的任意文件，在这里 id 通常是正在被引用的根功能部件的 id。您可以在链接文件目标中定义不只一个功能部件，并且名字命名为 foo.link 也是可以接受的。给出一个包含如下内容的链接文件：

path=E:/Eclipse-2.1.1/installedFeatures/Examples

Eclipse 将会到指定的目录下去查找 eclipse\features 目录和 eclipse\plugins 目录，看是否有合法的功能部件和（或）插件。也就是说，目标目录必须包含一个 \eclipse 目录。如果找到，附加的功能部件和插件在运行期配置是将是可用的，如果链接文件是在工作区创建之后添加的，附加的功能部件和插件会作为新的 配置变更 来处理。

使用链接文件来定制您自己的 Eclipse 安装设置的策略将在本文稍后的 使用链接文件管理 Eclipse 安装设置中进行讨论。

配置更新――添加一个功能部件

如果一个新的功能部件及所用到的插件已经添加到已有的 \features 目录和 \plugins 目录下，或者通过一个链接文件注册到 Eclipse，校验和的变化将触发配置处理过程。这个处理在一个简单的 splash-flash之后进行。新的功能部件作为一个配置变更来处理，并且显示出一个配置变更的对话框。

例如，如果您打开一个标准的 Eclipse 解压缩环境的工作区，而后找到了 Eclipse Examples，您把它解压缩到与 Eclipse 同样的目录树中或者添加了一个链接文件来指明这个例子解压缩到了何处，将会出现一个如图1所示的对话框。

图 1. 配置变更对话框

所以，如果您看到类似于这样的一个对话框，那是因为在您运行一个安装配置程序的时，您自己或者其他人修改了 Eclipse 的配置，而平台发现了新的或者更新过的可用功能部件。如果条目可以被选中，您可以将这个变化添加到您当前的配置中。如果条目被禁用，说明存在配置上的问题，这个功能部件不能被添加进来。按下 Error Details 按钮可以查看有关配置问题的信息。

配置管理注解：

存在未决变更并不意味着您不得不马上接受它们，在相当一段时间内您完全可以不去理会它们，只需要取消对条目的选择，并点击 Finish即可。要在以后再添加它们，您可以选择　 Help > Software Updates > Pending Changes...　来再次打开那个对话框。

已经被接受的变更在以后还可以禁用。打开 Install/Update 透视图，在 Install Configuration 视图中选中功能部件，然后在 Preview视图中选择 Disable 。禁用的功能部件还可以通过类似的步骤启用。在 Install Configuration视图中点击 Show Disabled Features图标可以显示被禁用的功能部件。

功能部件在运行期标识组件

Eclipse 允许标识活动产品，也可以选择标识运行期配置中的每一个功能部件。功能部件不是必须要标识出来，您可以不标识您所有的功能部件，但是您应该至少标识一个。

标识定义――插件的工作

添加标识的关键问题是要明白把标识的定义在哪里。您定义标识的是功能部件，但是标识的内容是来自于插件。或者插件与功能部件的 id 相同（默认的情形），或者插件在功能部件的定义中被明确标识（这是 Eclipse 2.1.1 的新增功能）。在 Eclipse 2.1 中，一个功能部件定义可以通过在 feature.xml 文件中指定属性 plugin=… 来定义其他插件。

插件包含了用于定义和提供标识内容的文件。

标识内容概要介绍

about.ini 控制文件定义了产品级和功能部件级的标识。产品标识必须正确包含以下两方面内容：

功能部件必须被定义为一个可能的主要功能部件，即在 feature.xml 定义文件中要包含 primary="true"。

功能部件必须被标识为活动的主要功能部件，在产品中通常是在 \eclipse 目录下的 install.ini 文件中的条目来设置。主要功能部件也可以在运行期通过使用 -feature featureId启动参数来定义。

理解功能部件标识的最简单的办法是去查看在 about.ini 控制文件中定义了哪些元素，以及它们在一个被标识的产品或功能部件中如何起作用。

图 2. 在 Eclipse 透视图中可用的标识内容

查看原图（大图）

以下几条仅用于产品标识：

windowImage

appName

aboutImage

其余条目在产品及功能部件标识过程中使用。

以百分号(%)开头的值在 about.properties 文件中解析。当一个功能部件是主要功能部件时，用 abouText 关键字定义的文本会在 About product 对话框中显示。当用户点击 Feature Details 按钮时，随后弹出的 About Features 对话框中也会显示这些本文内容。

功能部件被加入到运行期配置时，会打开 welcomePage 条目指定的欢迎页面，其后还可以通过选择 Eclipse 菜单选项 Help > Welcome... 打开的 Welcome 选择对话框打开这个欢迎页面。

构建一个可行的有标识的功能部件的最快速方法是克隆一个在 Eclipse 本身中可以找到的一个现有的功能部件。具有 org.eclipse.platform id 的功能部件和插件会提供功能部件标识和插件标识。在The Java Developer's Guide to Eclipse一书第34章练习7中有一个步骤详尽的指导说明。

在 Eclipse.org 的更新管理器子工程的开发资源中，您可以找到另外一些关于标识的详细说明。

使用 PDE 构建功能部件的策略

在The Java Developer's Guide to Eclipse一书中关于功能部件开发的章节和 Eclipse.org 的文章 "PDE 生成插件"中都对构建功能部件的过程进行了介绍，但是也还有一些其他的途径。当您理解了如何使用 PDE 来构建功能部件和相关联的插件之后，您可以让这些步骤自动完成。

由 PDE 实现的 Ant 目标

让我们从对 PDE 所提供功能概要介绍开始讲起。PDE 将为一个 plugin.xml 或 feature.xml 文件生成 build.xml 文件。Build.xml是一个 Ant 脚本，可以完成运行期平台的功能部件和插件所需要的不同任务。PDE 构建过程允许您生成下列构建目标中的一个或多个。

重要的功能部件构建目标：

build.jars为每一个引用到的插件调用 build.xml 文件中的 build.jars 任务。

build.update.jar 为每一个引用到的插件调用 build.xml 文件中的 build.update.jars 任务。同时会为功能部件创建一个 Update JAR。这是 Ant 脚本的默认目标。

build.sources为每一个引用到的插件调用 build.xml 文件中的 build.source 任务。

zip.distribution创建一个包含功能部件和引用到的插件所需要的所有文件的压缩文件。

refresh使 Eclipse 刷新功能部件工程及任何引用到的插件的工程。

重要的插件构建目标：

build.jars 为插件定义的每一个运行期 JAR 调用 build.xml 文件中的许多目标。被调用的目标的名字与运行期 JAR 文件的名字相同。这些目标编译 Java 代码并创建 JAR 文件，包含任何在源文件目录下的资源。

build.update.jar 将所有运行期插件目录下所有需要的文件压缩打包为一个名字为 plugin.id_version.jar 的文件，在这里 plugin.id 和 version 来自于 plugin.xml 文件。这是 Ant 脚本的默认目标。

build.sources基于给定的运行期 JAR 文件所定义的源文件目录，创建 Java 源文件的压缩包。

zip.plugin创建一个包含有插件所需要的所有内容的压缩包。

refresh使 Eclipse 刷新插件工程。

注意：在功能部件和插件的Ant 处理过程中，更新 JAR 或生成压缩包的处理过程中打包的文件，是运行期环境所需要的那些文件。这些内容在功能部件或插件的 build.properties 文件和在 plugin.xml 中定义的每一个插件的运行期 JAR 文件中，通过 bin.includes 或者 bin.excludes 条目来描述。

为了构建一个插件，您可能会指定 clean，build.sources，build.jars，zip.plugin，refresh。为了构建一个功能部件，您可能会指定 clean，build.sources，build.jars，zip.distribution，refresh。您或许会想要在开始时使用 clean 来强制重新生成所有结果，经常会有这种情况。尽管 Ant 处理过程将基于输入的变化重新执行所需要的步骤，但是有一些变化不会触发所有需要的处理过程。测试结果表明如果您改变了一个 Java 源文件，相应的源文件压缩包将会更新，但是类不会被重新编译，运行期 JAR 也不会被更新。所以安全起见，建议您先将输出结果清空，以保证您在重新构建后所使用的是对应于当前源文件的运行期版本。

讨论方案

为了进行讨论，我们先描述一下只有一个功能部件和插件时在运行期配置中需要的内容。

组件结构示例

包含策略――指出所需要的部分

至少到刚开始时，最简单的方法是，在构建过程中将您要打包的部分作为在运行期配置中功能部件或插件的一部分而列出来。相应的 build.properties 文件分别如下所示：

build.properties 内容

排斥策略――指定不需要的或私有的部分

另一种方法是把您不想打包的部分在构建过程中作为功能部件或插件的一部分列出来。这不仅要包括您不想共享的文件，还要包括构建过程中创建的文件和目录（有一些是临时的）。这种方法用到的 build.properties 文件如下：

build.properties 内容

如果给定功能部件或插件的 id 值为 com.your.feature.id 或者 com.your.plugin.id，那么您在使用排斥策略的时候还需要在文件中包括以下条目：

com.your.feature.id_1.0.0.bin.dist.zip,\
com.your.feature.id_1.0.0.jar,\
com.your.plugin.id_1.0.0.jar,\

zip 条目将使生成的组件压缩包不被 update JAR 或者组件压缩包自己所包含。JAR 条目将使生成的功能部件或插件的 update JAR 不被组件压缩包或者 update JAR 自己所包含。

当您的组件压缩包或者 update JAR 看起来比它应该的大小要大，或者在每次您进行编译时包的大小呈跳跃式增长，说明您应该执行以上步骤了。您需要在适当的功能部件或者插件的 build.properties 文件中加入以上条目来解决这个问题。

对文件或者结构变化的响应

除了以上提到的之外，当一个新的文件或目录添加到功能部件或者插件时，还有必需的响应需要考虑。我们的意思是您得让您的功能部件和插件能应付可能的改变，也就是说它们分别需要一个 feature.properties 文件和一个 plugin.properties 文件。当您用包含策略时，您需要给 .properties 文件添加一个适当的属性，如果是使用排斥策略的话就不用这样做了。

不论哪种方法，如果您把一个文件添加到一个目录，那么不需要做任何其他的改动。对于新添加的文件，如果使用的是包含策略，它会被发送处理，如果使用的是排斥策略，它将不会被发送处理。这实际上是您可能应该要考虑使用不同的目录来存放不同的文件的原因。例如，您的插件所用到的所有图片所在的目录应该被包含在内，而一个开发过程中存放插件的设计讨论或文档的目录则不然。

最坏的情形是当您忘记对 build.properties 进行更新时：会发生运行期失败或生成内容存在差错的产品。如果您使用包含策略，新加入的文件或目录在打包后是不可用的，这有可能会导致您的插件不能用或者显示出 Eclipse 默认的图标（红盒子）。如果是使用排斥策略添加新文件或目录，这些文件或目录的内容在打包过程中会被包含进来。根据您的风格选择适当的方法，从而把您忘记执行更新时的风险降到最低。这将取决于您所面临的主要问题：是功能部件或插件不能运行，还是其他人本不应该看到运行期目录下的文件。

组织功能部件

当您在开发您的工具时，您是否考虑到了需要多少个插件？答案是至少三个：一个是您的模型，也就是非 UI 的核心部分，一个是您的 UI 内容，还有一个或多个是用于提供帮助内容。如果您注意过，您会发现这是 Eclipse 本身的基本模式（jdt.core, jdt.ui, jdt.doc; debug.core, debug.ui;等等）。

这样划分的原因之一是，相对于不用于 UI 的插件来说，用于 UI 的插件在运行期需要不同的 Eclipse 组件的支持（org.eclipse.ui）。

包含其他功能部件

功能部件如果没有被其他功能部件包含，那么在 Eclipse 配置中都会被配置为根功能部件。默认情况下，根功能部件可以由用户在 Install/Update 透视图中禁用或启用，并且可以在 feature.xml 文件中确定一个更新 URL。当包含一个功能部件时，只有在根功能部件中的更新 URL 会被处理，否则只能通过 search-location 定义特别许可才可以。

通过包含功能部件，您可以管理包的组织结构。您可能会有多个功能部件，但只有一个做过标识，其余的或者是用来构成结构，或者是用来管理组件。请记住是根功能部件来定义更新的站点，尽管这个角色可以由功能部件委派给它所包含的功能部件，通过设置 search-location 属性值为 selfboth。

如果您正在构建一个基于 Eclipse 的产品，您可能希望您的一个功能部件来包含 Eclipse 功能部件树。对于标识这个产品来说这并不需要，但是您可以指定另外的更新站点（Eclipse 自己用的是 http://update.eclipse.org/updates），或者根本不指定更新站点，禁用基于 Web 的更新。

可选功能部件的角色

当将一个功能部件包含到另一个功能部件时，您可以选择是否把它设置为可选的。主要原因是创建这样的结构可以让用户根据他自己的需要来禁用您提供的组件的一部分。

当新的功能部件包含有可选功能部件，但那些可选功能部件并不存在时，Eclipse 的配置逻辑不允许添加这个新的功能部件。也就是说，如果适当的先决条件成立，可以使用可选功能部件来创建层结构。不过需要将这些层存贮在不同的目录树下，并且每层使用单独的链接文件。您可以添加到 Eclipse 配置以增加其功能的链接文件的没有数目上的限制。

让 Eclipse (或者任何基于 Eclipse 的产品)以您的方式工作

现在向您讲明了两点：指定的主要功能部件控制整个产品的标识和默认属性，Eclipse 可以在安装配置目录下或者任何一个链接的 Eclipse 目录结构下找到组件。这意味着您可以改变 Eclipse (存在相关风险，不过仅仅意味着您修改时需要小心！)。这些改变可以帮助您管理基于 Eclipse 的安装配置，并使之支持您个人所喜好的属性规则。

使用链接文件来管理 Eclipse 安装配置

您可能会希望能对环境进行更多的管理，而不是毫无选择地将所有的插件（我希望是引用到的功能部件）全部安装到您的 Eclipse 目录树下。如果您需要更新 Eclipse，实际上您并不想要另外再装一个新的 Eclipse 或者在列表中去查找您所想要的功能部件和插件。

下面是一种借助链接文件来组织您的 Eclipse 或者基于 Eclipse 的产品和构件的方法：

保持 Eclipse 或者基于 Eclipse 的产品是干净的。也就是说，不要把您的任何功能部件或者插件添加到 eclipse\features 和 eclipse\plugins 目录下。

在已有的 eclipse 目录下创建一个 eclipse\links 目录和一个 eclipse\links-out 目录。如果您用的是基于 Eclipse 的产品，那么可能已经存在 eclipse\links-out 目录。这个目录并不特殊，只是一个用来方便存放不用的链接文件的地方。

为您要添加到您的配置中的功能部件和插件创建一个或多个 add-ons 的目录。在这些目录下，创建一个 eclipse\features 和一个 eclipse\plugins 目录结构。

为每一个 add-ons 目录在 eclipse\links-out 目录下创建一个链接文件。将那些您当前要添加到您的活动配置中去的链接文件拷贝到 eclipse\links 目录。

例如，假定您将 Eclipse 解压缩到一个名为 Eclipse-2.1.1 的目录下，然后创建一个名为 CoolTools 的 add-ons 目录，也放在 Eclipse-2.1.1 目录下。在 CoolTools 目录下，您可以有多个目录，每个目录用于一个或一族您要添加到 Eclipse 的工具。您的目录结构可能会如图3所示。

图 3. Eclipse 的链接文件目录结构

EditorList.link 文件要包含下面其中一条（不能是全部）

path=D:/Eclipse-2.1.1/CoolTools/EditorList
path=D:\\Eclipse-2.1.1\\CoolTools\\EditorList

斜杠是一条（/）还是两条（\\）取决于目录结构。

确认条目不要以空格结尾，因为这样 Eclipse 会忽略它――我第一次用链接文件时用了好几个小时才弄明白这一点。

如果您使用一个新的工作区来启动 Eclipse，所有 Eclipse 自带的以及通过链接文件找到的功能部件和插件都是可用的。如果您要添加一个链接文件，并使用现有的工作区重新启动 Eclipse，Configuration Changes 对话框就会弹出。如果您删除了一个链接文件（很简单，只是把它移到 \links-out 目录下），配置的变化也会被 Eclipse 注意到，但您能看到的仅仅是 splash-flash。

实际上您不是必须将链接文件移入移出来控制配置，更好的办法是用 Install/Update 透视图来调整配置。当然，可以这样做的前提是您的插件都属于功能部件（看，这是另外一个需要功能部件的理由）。使用 Eclipse 进行配置的调整将以后面讨论。

使用 Install/Update 透视图来修改配置

根功能部件，以及任何定义为可选择的功能部件，都可以在当前配置中禁用。被禁用后，功能部件仍然可以被平台认出；它们只是不再包含在当前的运行期配置中。

前面我们谈及了将 Eclipse Examples 添加到活动配置中。添加后，我们可以使用 Install/Update 透视图来禁用它。如果您正打开一个包含有 Eclipse Examples 的 Eclipse 配置的 Install/Update 透视图，您看到的将如图4 所示。

图 4. 在 Install/Update 透视图中的 Eclipse Examples 功能部件

查看原图（大图）

在 Preview 视图中点击 Disable Now 按钮，您就可以将 Eclipse Examples 功能部件从运行期配置中临时移除。点击后，Eclipse 将提示您重新启动平台来使配置的修改生效。

Eclipse Examples 功能部件在当前配置中将不再可见（或者说不是活动的）。为了能再次看到这个功能部件并启用之，您需要在 Install Configuration 视图中点击 Show Disabled Features开关按钮（见图5）。

图 5. 在Install/Update 透视图中禁用 Eclipse Examples 功能部件

查看原图（大图）

由于 Eclipse Examples 功能部件是一个根功能部件，所以可以这样做。如果您在 Eclipse SDK 中浏览其他功能部件，您将发现它们在 Preview 视图中没有相应的 Disable Now按钮，这是因为它们被定义为必需的。

如果您用的是 Eclipse SDK，您应该会有默认配置的平台、JDT 和 PDE。如果您正在做一些插件的开发，但是您不需要 PDE——或者在一些情况下，您不是总需要 JDT——您只要对 Eclipse 做一个小的修改就可以禁用这些功能部件。打开 org.eclipse.platform.sdk.win32 功能部件的 feature.xml 文件，将以下几行修改为包含 optional="true" 属性。

清单 1. 禁用 PDE 和 JDT
<includes　id="org.eclipse.platform.win32"　version="2.1.1"　match="equivalent"/>　
<includes　id="org.eclipse.jdt"　version="2.1.1"　match="equivalent"　optional="true"/>　
<includes　id="org.eclipse.pde"　version="2.1.0"　match="equivalent"　optional="true"/>　
<includes　id="org.eclipse.platform.win32.source"　version="2.1.1"　match="equivalent"　
　　optional="true"/>　
<includes　id="org.eclipse.jdt.source"　version="2.1.1"　match="equivalent"　optional="true"/>　

现在您可以在 Install Configuration 视图中选择这些功能部件并禁用它们。如果所有前面提到那些定义为可选择的功能部件都被禁用，平台依然可以运行。并且，您随时可以重新启用它们。图6 是 Install Configuration 视图中显示的被禁用的功能部件。

图 6. 禁用 Eclipse 多个的功能部件

查看原图（大图）

这些禁用/启用的设置都是仅对于当前工作区有效。您可以有另外的活动工作区，其中包含有部分或全部在当前工作区中被禁用的功能部件。

这个简单的例子说明了使用功能部件的优势（它们可以被禁用）和使用链接文件来将所有可能的功能部件添加到您的配置的意义所在。在一个给定的工作区中将您所不需要的功能部件禁用，这样就可以优化当前配置。

定义自己的全局属性

Eclipse 是一个优秀的工具，但是同任何工具一样，您得对它进行定制，它才能是完美的。工具提供了属性页面来让您改变工具的行为或可视化显示。最新统计，在 Eclipse 中有 62 个属性页面。几乎每次您使用到一个新工具，您都会发现有些选项您想要修改。但是当您使用多个工作空间时，或者是在一个团队的环境中工作，有一些选项需要与他人协调，这样就出现了如何在跨工作空间以及与他人协调工作时对选项进行最佳管理的问题。

Eclipse 提供了导入/导出属性的功能。在任何一个属性对话框中，您都可以将属性导出到一个 .epf 文件中。当使用其他工作区或与他人共享时，可以再次导入这个文件。您甚至可以将它添加到工程中与团队成员共享，以便每个人都可以得到标准的属性。

但是这样做会变得单调而乏味，并且如果您忘记了就麻烦了。在使用 Eclipse 或任何基于 Eclipse 的产品时，您应该意识到还有另外一种方法可以定义全局属性。您可以通过修改主要功能部件的 plugin_customization.ini 文件来定制属性的默认值。

您可以在 eclipse 目录下的 install.ini 文件中找到主要功能部件。例如，在标准的 Eclipse 解压缩中的 install.ini 的内容如下：

清单 2. 标准的 Eclipse 解压缩中的 install.ini 的内容
#　install.ini　
#　java.io.Properties　file　(ISO　8859-1　with　"\"　escapes)　
#　This　file　does　not　need　to　be　translated.　
#　Required　property　"feature.default.id"　contains　the　id　of　the　primary　feature　
#　(the　primary　feature　controls　product　branding,　splash　screens,　and　plug-in　customization)　
feature.default.id=org.eclipse.platform　
#　Required　property　"feature.default.application"　contains　id　of　the　core　
#　application　that　gets　control　on　startup.　For　products　with　a　UI,　this　
#　is　always　org.eclipse.ui.workbench;　for　"headless"　products,　this　is　product-specific.　
feature.default.application=org.eclipse.ui.workbench　

feature.default.id=… 指定了默认的主要功能部件。要注意的是，通过在启动 Eclipse 时使用 -feature 选项，可以把其他功能部件声明为是主要的。

同大部分功能部件控制和标识一样，实际的工作都是在功能部件相关联的插件中完成的。对于 Eclipse来说，这是一个 id 与功能部件相同的插件，org.eclipse.platform 插件。如果您仔细查看这个作为主要功能部件标识的插件，您将发现一个名为 plugin_customization.ini 的文件。这个文件的内容与导出属性的文件类似。当 Eclipse 启动时会读取这个文件，并用来指定所有默认的属性值，而不是去使用插件本身定义的那些值。这就使得产品，或者说是您，可以改变插件的行为。默认的 plugin_customization.ini 文件的内容只有一条：

清单 3. 默认的 plugin_customization.ini 文件
#　plugin_customization.ini　
#　sets　default　values　for　plug-in-specific　preferences　
#　keys　are　qualified　by　plug-in　id　
#　e.g.,　com.example.acmeplugin/myproperty=myvalue　
#　java.io.Properties　file　(ISO　8859-1　with　"\"　escapes)　
#　"%key"　are　externalized　strings　defined　in　plugin_customization.properties　
#　This　file　does　not　need　to　be　translated.　
#　Property　"org.eclipse.ui/defaultPerspectiveId"　controls　the　
#　perspective　that　the　workbench　opens　initially　
org.eclipse.ui/defaultPerspectiveId=org.eclipse.ui.resourcePerspective　

这一条目指定了打开新的工作区时以及当您关掉所有的透视图后关闭 Eclipse 时打开的透视图。如果您使用的基于 Eclipse 的产品，这个条目可能有所不同。

指定要包含的属性的过程比较费事，但至少您应该做如下步骤：

启动一个干净的工作区。

修改您想要改变的一个属性。

将属性导出到一个 .epf 文件。

在导出的文件中找到新的健值，并确定它是否反映了您刚刚所做的改变。

将一个或多个键的条目拷贝到标识插件（使用 Eclipse 时这个插件是 org.eclipse.platform）的 plugin_customization.ini 文件中。

测试结果，或者保留新的键，或者再试一次。

注意：如果您不习惯于去更新产品的 plugin_customization.ini 文件，您可以在其他位置创建一个这个文件的拷贝，在启动 Eclipse 或基于 Eclipse 的产品时使用参数来指定它。

eclipse　-plugincustomization　myCustomDefaults.ini　

全局属性示例

前面提到了一些相关技术的描述，并提出了对您可能希望包含到您定制的 plugin_customization.ini 文件中的一些值的建议，这里给出了示例属性重写，作为对前面两方面的内容的说明。

我们将把它们根据我定制的目的在逻辑上分为的几部分来介绍。您可以下载完全的 插件 customization.ini 文件。

视图栏默认是在底部，但我喜欢把它们放在顶部：
#　View　tabs　at　the　bottom　
org.eclipse.ui.workbench/VIEW_TAB_POSITION=128　

新工作区打开时不打开欢迎页面，并且在关闭工作台时不再提示：
#　No　welcome　dialog　at　open　and　no　confirm　on　close　
org.eclipse.ui.workbench/WELCOME_DIALOG=false　
org.eclipse.ui.workbench/EXIT_PROMPT_ON_CLOSE_LAST_WINDOW=false　

在打开新工程向导所知的透视图时，禁用提示或其他动作：
#　Never　change　to　perspective　required　by　new　project　wizard　(no　prompt)　
org.eclipse.ui.workbench/SWITCH_PERSPECTIVE_ON_PROJECT_CREATION=never　

定义另外的默认文本字体：
#　Default　text　font　(leaks　into　Java　editor)　
#　Note:　you　have　to　touch　the　font　page　and　say　OK/Apply　(probable　bug)　
org.eclipse.ui.workbench/org.eclipse.jface.textfont=　
　1|Lucida　Console|9|1|WINDOWS|1|-15|0|0|0|700|0|0|0|0|3|2|1|49|Lucida　Console;　

注意：字体属性条目比较特殊，对它的修改不会立即生效。如果您访问字体属性页，前面所定义的内容会显示出来，不过得在您选择了 OK 或者 Apply 之后才会生效。我不能让这个键保存下来用于 Java 文本字体。

预定义附加的 Java 编辑器任务标签：
#　Add　to　the　default　JDT　task　tags　(TODO　should　probably　be　left)　
org.eclipse.jdt.core/org.eclipse.jdt.core.compiler.taskTags=TODO,Edu-Sol　

将对 Package Explorer 的双击默认设置为 Go Into 动作：
#　Package　Explorer　GoInto　on　Double　click　
org.eclipse.jdt.ui/packageview.doubleclick=packageview.gointo　

有一些没有定义属性页面的选项也是可以定制的。在完成对 UI 的标准设置后导出的 .epf 文件中，我发现有一些 JDT 的选项值是作为属性来保存的。

这个属性键是用于告知 JDT UI 它要读取属性并用来改变默认的 UI 行为：
#　Tells　JDT　it　does　have　some　prefs　to　use　(forces　a　read　of　these　values)　
org.eclipse.jdt.ui/CustomFiltersActionGroup.org.eclipse.jdt.ui.PackageExplorer.　
　TAG_DUMMY_TO_TEST_EXISTENCE=storedViewPreferences　

注意：如果没有上面的这个属性键，接下来的两组设置将被忽略。

活动 Package Explorer 过滤器以属性值的形式保存：
#　Package　Explorer　filter　-　standard　JDT　defaults　+　library　filter　
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer.LibraryFilter=true　
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer_patternFilterId_.*=true　
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer.PackageDeclarationFilter=true　
org.eclipse.jdt.ui/org.eclipse.jdt.ui.PackageExplorer_patternFilterId_*$*.class=true　
org.eclipse.jdt.ui/org.eclipse.jdt.internal.ui.PackageExplorer.EmptyInnerPackageFilter=true　

Outline 视图有一个显示选项，可以在活动的 JDT Java 编辑器中显示内容时减小树的深度。这个图标有一个悬浮帮助 Go Into Top Level Type，由下面这个属性项来控制： #　Outline　view　GoInto　Toggle　when　using　JDT　editor　
org.eclipse.jdt.ui/GoIntoTopLevelTypeAction.isChecked=true　

您可能会想要尝试为更多的属性指定新的默认值，使用前面描述的方法然后核对一下结果即可。您或许会希望在一个临时的工作区中做这些事情，达到修改的目的后，您可以按此去修改活动的主要功能部件的 plugin_customization.ini 文件（不要告诉任何人是我教您这样做的！）。并且要注意的是，您可能会发现其他一些键被忽略了，这种情况我也曾遇到过，因为字体是用于 JDT 的，因此这一条目加入到 plugin_customization.ini 文件后，在属性页中根本就不会体现出这种变化。

结束语

功能部件是 Eclipse 的幕后英雄－－它们很重要，因为它们是 Eclipse 配置管理的组成部分，支持产品标识，并且它们是在 Eclipse 平台上构建定制解决方案的产品的一部分。使用功能部件您可以：

当您使用基于 Eclipse 的产品进行工作时，您可以根据功能部件标识鉴别出是谁提供了哪些不同的可用功能

对产品的标识可以帮助进一步定制 Eclipse

在插件开发环境中自动完成任务

通过禁用/启用根功能部件，或者使用 Install/Update 透视图来禁用/启用定义为可选的被包含的功能部件，您可以动态地改变给定工作区的配置

所以，使用功能部件吧，它可以帮助您自动完成构建插件的一些步骤，使用文中提到的自定义 install/link 文件组织方法，可以使您的 Eclipse 环境更加好用。