eclipse功能_使Eclipse功能为您服务

最新推荐文章于 2024-03-24 12:27:04 发布

cuxiong8996

最新推荐文章于 2024-03-24 12:27:04 发布

阅读量942

点赞数

文章标签：大数据 python 人工智能 java linux

原文链接：https://www.ibm.com/developerworks/opensource/library/os-ecfeat/index.html

版权

eclipse功能

构建插件是一个有趣的部分：您可以编写代码并创建所需的工具。然后，只需将插件复制到Eclipse或基于Eclipse的产品的现有\ plugins目录中，即可在Eclipse运行时环境中使用该插件。启动Eclipse时，将找到该插件，并且如果它通过了平台启动处理，那么它将在运行时配置中可用。

但是谁知道或关心您的插件加入了聚会呢？用户会理解您的工具所提供的功能吗？他们将能够使用Eclipse禁用，服务或以其他方式管理您的贡献吗？绝对不。插件本身只是一个插件，而不是与Eclipse Platform完全集成的工具。

功能包插件

没有功能的插件变得不规则。或者，使用常见的说法，没有功能的插件是非托管插件。 Eclipse Platform启动包含一个配置步骤。如果将新插件复制到\ plugins目录中，或者在启动时以其他方式使Eclipse知道，则配置步骤会引起注意，但仅通过闪烁两次启动映像即可让您知道。 Eclipse注意到了新插件，因为存储在\ .metadata \ .config \ platform.cfg文件中的当前工作区的配置校验和不同。 Eclipse可以做的只是闪动，因为您没有提供平台可以用来指导用户进行配置修改的功能。通过将插件打包为一个或多个功能，您将有机会：

列出您的贡献的先决条件（在feature.xml文件中），以便在Eclipse配置处理期间使用。
作为活动Eclipse配置的一部分，管理您的贡献。
提供品牌信息，以标识您对使用运行时环境的用户所做的贡献，以及一个欢迎页面，该页面告诉用户功能提供的功能（在与功能关联的welcome.xml文件中）。
可以使用Eclipse更新管理器来服务您的贡献。

不要等到插件开发任务结束后再添加功能包。功能定义中反映的设计决策可能会影响插件的结构。例如，大多数Eclipse贡献都具有UI和核心（非UI）功能。如果您的插件未采用这种方式进行细分，则可能需要考虑对它们进行一些重新设计。功能也可以用于自动化所引用插件的构建过程。

主要功能为产品打上商标（但您可以控制）

有很多功能，但是启动Eclipse时只有一个功能在控制之中。此主要功能可识别产品品牌和其他运行时行为。这包括为运行时平台标识名称和关联的图形，以及为所有插件重新定义默认首选项的选项。正如在定义自己的全局首选项中所看到的，这可以是一个强大的选项，可用于自定义自己的Eclipse安装。

功能构建插件（如果允许的话）

PDE将自动执行大部分任务，以为完整的运行时环境准备功能部件和插件内容。请参阅Eclipse.org的文章“PDE生成插件”中讨论（见相关主题）。《 Eclipse Java开发人员指南》（请参阅参考资料）中还记录了这些基本步骤，您可以按照此练习来构建和标记现有插件。只需说明一下，如果您具有功能并了解PDE如何帮助您构建插件和功能，则可以构建功能并让它同时构建所有关联的插件。在使用PDE构建 bin.includes 策略中讨论了构建控制策略（ bin.excludes与bin.includes ）。这些策略补充了您可以从Eclipse.org文章和Java开发人员指南Eclipse中学习到的内容。

平台配置管理

要了解功能的需求，有助于了解它们如何管理活动配置中的可用内容。

启动处理

给定Eclipse Platform的全新解压缩后，启动eclipse.exe时将发生以下情况：

找到了Java™运行时环境（JRE）。默认情况下，Eclipse首先在eclipse \ jre子目录中查找一个。如果找不到Eclipse，Eclipse将寻找操作系统已知的一个。
注意： -vm dir-location参数始终可用于标识备用JRE。
配置被创建为新工作空间的一部分。新的工作区通常没有配置，这就是为什么您在真正的启动映像之前看到一个显示“正在完成安装”的映像的原因。
处理Eclipse已知的功能部件和插件，并创建校验和以检测将来的变化。这包括当前eclipse \ features和eclipse \ plugins目录中的功能和插件，以及由链接文件标识的eclipse \ ...目录结构。

如果工作空间已经存在，它将在.metadata \ .config \ platform.cfg文件中包含一个配置。

如果像正式安装的产品一样管理Eclipse安装，则可以通过运行eclipse -initialize命令在eclipse \ .config目录中建立默认的初始配置。使用新的工作区时，这使得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知道，则校验和更改将触发配置处理。这种处理超出了简单的闪屏。新功能将作为配置更改处理，并显示“配置更改”对话框。

例如，如果您使用标准Eclipse解压缩打开了一个工作区，然后又找到了Eclipse示例并将其解压缩到与Eclipse相同的目录树中，或者添加了一个指向示例的位置的链接文件，则将显示图1中的对话框。解压缩。

图1.配置更改对话框

因此，如果看到这样的对话框，那是因为您，您运行的安装程序或者其他人修改了Eclipse安装，因此可以使用新的或更新的功能。如果可以选择条目，则可以将更改添加到当前配置。如果禁用了条目，则存在配置问题，无法添加新功能。 错误详细信息按钮提供有关配置问题的信息。

配置管理注意事项：

仅仅因为有待更改，并不意味着您现在必须接受它们。您可以将更改留待一段时间。只需取消选择条目，然后单击完成。要在以后添加它们，请使用菜单选项“ 帮助”>“软件更新”>“待更改... ”再次打开对话框。
接受的更改以后可以禁用。打开“安装/更新”透视图，然后在“安装配置”视图中选择功能，然后在“预览”视图中选择“ 禁用 ”。禁用的功能可以稍后使用相同的过程再次启用。要在“安装配置”视图中查看禁用的功能 ，请选择“ 显示禁用的功能”切换。

特色品牌可以在运行时识别您的贡献

Eclipse允许对活动产品以及运行时配置中包括的每个功能进行品牌化。不需要对品牌进行品牌化，您可以选择不对所有功能进行品牌化，但您应该对至少一个品牌进行品牌化。

品牌定义-插件的工作

添加商标的技巧是知道将定义放在何处。您具有品牌特征，但品牌内容是由插件提供的。这是与功能部件具有相同ID的插件（缺省处理），或者是功能部件定义中标识的插件（Eclipse V2.1.1中的选项）。 Eclipse V2.1中的功能定义可以使用feature.xml文件中的plugin=...属性来定义备用插件。

该插件包含用于定义和提供品牌内容的文件。

品牌内容概述

about.ini控件文件为产品和功能级别的商标定义商标内容。对于产品品牌，必须满足以下两个条件：

该功能必须定义为可能的主要功能。这意味着它在feature.xml定义中包含primary="true" 。
该功能必须被标识为活动的主要功能。通常在产品中使用\ eclipse目录中install.ini文件中的条目来完成此操作。也可以在运行时使用-feature featureId启动参数来定义主要功能。

理解功能商标的最简单方法是查看about.ini控件文件中定义了哪些元素以及它们在品牌产品或功能中的位置（请参见图2）。

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

这些条目仅适用于产品品牌：

windowImage
appName
aboutImage

其余条目将在产品和功能商标期间使用。

带有百分号（ % ）的值在about.properties文件中解析。当功能是活动的主要功能时，使用aboutText键定义的文本在“ 关于产品”对话框中可用。在“ 关于功能”对话框中选择可以使用“ 功能详细信息”按钮打开的任何功能时，也会显示该文本。

最初将功能添加到运行时配置时，将打开由welcomePage条目标识的welcomePage并且以后总是可以使用使用Eclipse中的“ 帮助”>“欢迎...”菜单选项打开的“ 欢迎”选择对话框来找到。

建立有效的品牌功能的最快方法是克隆Eclipse本身中的条目。 ID为org.eclipse.platform功能部件和插件提供功能部件和插件品牌。《 Eclipse Java开发人员指南》的“第34章，练习7”中也包含分步指南。

您可以在为更新管理器子项目的开发资源（见Eclipse.org品牌找到更多详细相关信息）。

使用PDE构建要素的策略

Eclipse Java开发人员指南和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.jar任务。它还为该功能创建一个Update JAR。这是Ant脚本的默认目标。
build.sources为每个引用的插件在build.xml文件中调用build.sources任务。
zip.distribution将创建该功能部件和引用的插件所需的所有文件的ZIP文件。
refresh告诉Eclipse刷新功能部件项目和任何引用的插件的项目。

感兴趣的插件构建目标：

对于为插件定义的每个运行时JAR， build.jars都会调用build.xml文件中的许多目标。调用的目标名称与运行时JAR文件名相同。这些目标编译Java代码并创建JAR文件，该文件包含源文件夹中保留的所有资源。
build.update.jar将运行时插件目录中所需的所有文件压缩到名为plugin.id _ version .jar的文件中，其中plugin.id和version来自plugin.xml文件。这是Ant脚本的默认目标。
build.sources基于为给定的运行时JAR文件定义的源文件夹创建Java源的ZIP文件。
zip.plugin创建一个ZIP文件，其中包含该插件的所有元素。
refresh告诉Eclipse刷新插件项目。

注意：在功能部件和插件Ant处理中，更新JAR或ZIP处理期间打包的文件是运行时环境中所需的文件。这些描述在功能或插件的build.properties文件中的bin.includes或bin.excludes条目中，以及在plugin.xml中定义的每个插件的运行时JAR文件中。

要构建插件，您可以说clean, build.sources, build.jars, zip.plugin, refresh 。要构建功能，您可以说clean, build.sources, build.jars, zip.distribution, refresh 。您希望从clean开始，以强制重新创建所有零件。这通常是必需的。尽管Ant处理将根据输入中的更改重新运行许多必需的步骤，但某些更改不会触发所有必需的处理。测试显示，如果更改一个Java源文件，则将更新相应的源ZIP，但不会编译该类，也不会更新运行时JAR。这表明先清理构建输出是更安全的，这样您就可以知道正在使用当前源的运行时版本。

讨论场景

出于讨论目的，让我们仅描述运行时配置中必需的一项功能和插件的内容。

表1.贡献结构示例

贡献类型	档案
特征	feature.xml
	feature_image.jpg
	/license/license.html
	/license/license.pdf
	/plan/project-plan.doc
插入	plugin.xml
	/images/action.gif
	/images/editor.gif
	/src/co/pkg/id/action.java
	/src/co/pkg/id/editor.java
	/design-docs/plug-in.doc
	/design-docs/editor.doc

从文件名可以看出，尽管大多数文件都属于运行时环境，但与他人共享的内容（例如，设计文档）中可能不应该包含其他文件。

包含策略-确定所需的位

最简单的方法（至少在最初是这样）是仅列出要在构建过程中打包的所有内容，并将其作为功能或插件的一部分在运行时配置中列出。每个的build.properties文件如下所示：

表2. build.properties的内容

零件	build.properties文件内容
特征	bin.includes = feature.xml，\ 执照/
插入	source.runtime.jar = src / bin.includes = plugin.xml，\ 图片/

排除策略-识别不需要或专用的位

另一种方法是在构建过程中列出您不想打包的功能或插件的一部分。这不仅必须包括您不想共享的内容，而且还必须包括通过构建处理创建的文件和目录（其中一些是临时的）。这种方法的build.properties文件如下所示：

表3. build.properties的内容

零件	build.properties文件内容
特征	bin.excludes = temp.folder /，\ com.ibm.master.lab.core_1.0.0.bin.dist.zip，\ .classpath，\ 。项目，\ build.xml，\ build.properties
插入	bin.excludes = temp.folder /，\ bin /，\ .classpath，\ 。项目，\ build.xml，\ build.properties，\ makerczip.xml，\ src /

给定com.your.feature.id或com.your.plugin.id的功能部件或插件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条目将阻止发行版ZIP包含在更新JAR或发行版zip本身中。 JAR条目将使功能或插件的更新JAR不会包含在分发ZIP或更新JAR本身中。

每次运行构建过程时，您的发行版ZIP或更新JAR看起来应该大于它的大小，或者其大小不断增加时，就表明有这种需要。这些条目将放入适当的功能部件或插件build.properties文件中。

对文件或结构更改的React

给定描述的选项，当将新文件或文件夹添加到功能部件或插件时，仍然需要考虑做出React。假设您准备好功能和插件以进行可能的翻译；这意味着您每个都需要一个feature.properties和plugin.properties文件。使用包含策略时，您需要添加对适当的.properties文件的引用，但是使用排除策略无需更改。

每种方法都是一致的，因为如果您将文件添加到目录中，则不需要更改。新文件将以包含方法发送，而不是以排除策略发送。这实际上表明了为什么您可能考虑对不同类型的文件使用特定目录。例如，将包含该插件使用的所有图像的图像目录，而将排除您在开发过程中与该插件保持在一起的任何设计讨论或文档的设计目录。

当您忘记进行build.properties更新时，最坏的情况是：运行时失败或不适当的内容交付。如果在使用包含策略时添加了新文件或目录，则打包后将无法使用它，这可能会导致插件失败或显示Eclipse默认映像（红色框）。如果在使用排除策略时添加新文件或目录，则打包过程中将包括文件或目录内容。选择适合自己风格的方法，并在您忘记进行更新时风险最小。选择的依据是让您更烦恼的事情：不运行的功能或插件，或者其他人不应该看到的运行时目录中的文件。

结构特征

在开发工具时，您是否考虑需要多少个插件？简短的答案可能是三个：一个用于模型或非UI核心，一个用于UI内容，一个或多个用于所提供的任何帮助内容。如果您看的话，您将看到Eclipse本身重复了这种基本模式（jdt.core，jdt.ui，jdt.doc； debug.core，debug.ui等）。

进行这种分离的一个原因是，与不提供UI内容的插件（ org.eclipse.ui ）相比，提供UI内容的插件在运行时需要Eclipse的不同部分。

包括其他功能

除非另一个功能包括这些功能，否则功能将配置为Eclipse配置中的根功能。默认情况下，用户可以在“安装/更新”透视图中禁用或启用根功能，并且可以在feature.xml文件中标识更新URL。除非包含功能部件时search-location定义明确允许，否则将仅处理根功能部件中的更新URL。

通过包含功能，您可以管理软件包的结构。您可能还具有多种功能，但只有品牌一项；其他提供结构或以其他方式管理贡献。请记住，根功能定义了更新站点，尽管当search-location属性与self值both使用时，包含该功能的角色可以由包含此功能的角色委派给包含的功能。

如果要构建基于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目录可能已经存在。该目录不是特殊的，只是不使用时隐藏链接文件的方便位置。
为要添加到配置中的功能和插件创建一个或多个加载项目录。在这些目录中，创建一个eclipse \ features和eclipse \ plugins目录结构。
对于每个加载项目录，在eclipse \ links-out目录中创建一个链接文件。将当前作为活动配置一部分所需的那些文件复制到eclipse \ links目录。

例如，假设您将Eclipse解压缩到名为Eclipse-2.1.1的目录中，然后在Eclipse-2.1.1目录中创建了一个名为CoolTools的加载项目录。在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，将显示“配置更改”对话框。如果删除链接文件（就像将其移到\ links-out一样容易），则会注意到配置更改，但是您将看到的只是一闪一闪的。

您实际上并不需要移入和移出链接文件来控制配置。更好的方法是仅使用“安装/更新”透视图调整配置。当然，这是假设您具有插件的功能（请参阅功能的另一个原因）。接下来讨论使用Eclipse进行配置调整。

使用“安装/更新”透视图进行配置修改

可以在当前配置中禁用根功能和定义为可选的任何功能。禁用后，平台仍将知道这些功能；它们只是不包括在当前的运行时配置中。

之前，我们讨论了将Eclipse示例添加到活动配置中。到达那里后，我们可以选择使用“安装/更新”透视图禁用它们。如果要打开包含Eclipse示例的Eclipse配置的Install / Update透视图，将会看到类似图4的内容。

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

通过选择“预览”视图中的“ 立即禁用”按钮，可以从运行时配置中临时删除Eclipse Examples功能部件。选中后，Eclipse将提示您重新启动平台以处理配置修改。

在当前配置中，Eclipse Examples功能部件将不再可见（或处于活动状态）。要查看该功能以便再次启用它，需要在“安装配置”视图中选择“ 显示禁用的功能”切换（请参见图5）。

图5.“安装/更新”透视图中的“禁用的Eclipse示例”功能

因为它是根功能，所以它适用于Eclipse Example功能。如果您探索Eclipse SDK中的其他功能，您将看到它们在“预览”视图中不包括“ 立即禁用”按钮。这是因为它们是按要求定义的。

如果使用的是Eclipse SDK，则默认情况下已配置了Platform，JDT和PDE。如果您进行一些插件开发，但是您不需要PDE（或者为此，您一直不需要JDT），那么您可以对Eclipse进行少量修改就可以禁用这些功能。打开org.eclipse.platform.sdk.win32功能的feature.xml文件，并更改以下org.eclipse.platform.sdk.win32行以包括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"/>

现在，您可以在“安装配置”视图中选择这些功能并禁用它们。如果以上定义的所有可选选项均被禁用，则平台仍将运行。请记住，您始终可以再次启用它们。图6显示了“安装配置”视图，其中显示了禁用的功能。

图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，这是与功能org.eclipse.platform插件具有相同ID的插件。如果您查看此插件（它是主要功能的品牌插件），则会找到一个名为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文件。
检查文件以识别新密钥，并确定它们是否映射到您刚进行的更改。
Copy one or more of the key entries to the plugin_customization.ini file in the branding plug-in (this is org.eclipse.platform when using Eclipse).
Test the result and either keep the new key or try again.

Note: If you are not comfortable with updating the product's plugin_customization.ini file, you can always create a copy of the file in another location and use a startup parameter that identifies the file when you start up Eclipse or an Eclipse-based product:

eclipse -plugincustomization myCustomDefaults.ini

Global preference examples

Example preference overrides are provided here as a demonstration of both the technique described above and suggestions for some values you may wish to include in your own customized plugin_customization.ini file.

We'll look at them in logical chunks based on goals I had for my customization.

View tabs default to the bottom, but I like them at the top:

# View tabs at the bottom
org.eclipse.ui.workbench/VIEW_TAB_POSITION=128

To not open the welcome pages for a new workspace and to stop the prompt when closing the workbench:

# 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

To disable the prompt or action to open a perspective known to the new project wizard:

# Never change to perspective required by new project wizard (no prompt)
org.eclipse.ui.workbench/SWITCH_PERSPECTIVE_ON_PROJECT_CREATION=never

To define an alternate default text font:
```
# 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;
```
Note: The font preference entry is peculiar. It does not take affect immediately. If you visit the font page, the font defined above is shown, and will be used once you select OK or Apply . I was unable to get the key saved for the Java text font to work.

To predefine an additional Java editor task tag:

# 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

To set the double-click default for the Package Explorer to be equivalent to the Go Into action:

# Package Explorer GoInto on Double click
org.eclipse.jdt.ui/packageview.doubleclick=packageview.gointo

Some customization is available even when the changes are not preference page-defined options. By glancing at the contents of an exported .epf after making my standard set of UI modifications, I noticed that some JDT decisions were stored as preferences.

This preference key is used to tell the JDT UI that it does have preferences to read to change the default UI behavior:

# 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

Note: If the above key is missing, the next two sets of entries will not be processed.

The active Package Explorer filters are stored as preference values:

# 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

The Outline view has a display option that reduces the tree depth when the view is showing content from an active JDT Java editor. The hover help Go Into Top Level Type is displayed for this toggle. This preferences entry controls this decision:
```
# Outline view GoInto Toggle when using JDT	editor
org.eclipse.jdt.ui/GoIntoTopLevelTypeAction.isChecked=true
```

You may want to experiment a bit to find more preference keys that you want to identify new defaults for. Use the described process and check the results. You might want to do this with a temporary workspace. When you are satisfied, you can modify the plugin_customization.ini file for the active primary feature (just don't tell anyone I told you to do so!). Also note that you may find other keys that seem to be ignored, as I did, for the font that was to be used by the JDT. This entry, when placed in the plugin_customization.ini file, did not change the preference page at all.

摘要

Features are the unsung hero of Eclipse — they are important because they are the unit of Eclipse configuration management, they support product branding, and they are part of how products build customized solutions on top of the Eclipse Platform. Using features you can:

Identify, based on feature branding, who provided the different functions that are available when you are working with an Eclipse-based product
Build on product branding capabilities to further customize Eclipse
Automate tasks in the plug-in development environment
Dynamically change the configuration for a given workspace by managing the enabled/disabled state of root features, or features included by another but defined as optional, using the Install/Update perspective

So, give features a go, if only to automate some of the plug-in build processing, or to make your own Eclipse environment better by using the customization install/link file structuring approaches covered here.

翻译自: https://www.ibm.com/developerworks/opensource/library/os-ecfeat/index.html