资源

本章将讨论资源架构，该架构由编程接口以及与工作空间相关的扩展点组成，并且由org.eclipse.core.resources插件实现。org.eclipse.core.resources插件提供了各种支持，包括对Navigator视图中可见资源的支持、资源事件处理的支持和资源属性的支持。

通过理解资源模型的结构，您可以有效地利用工作空间API来创建资源和管理资源，并且动态地对资源的各种更改作出反应。

23.1  资源的概念

如果您已经使用过Eclipse来创建Java程序或者开发自己的插件，那么一定有过在工作空间定义资源和使用工具的经验。这些工具负责与资源模型进行交互，它们使用工作空间API与可见资源和资源模型内在的功能进行交互。我们将从考虑资源模型的物理实现开始，然后再探讨资源模型的逻辑视图。

首先，让我们来定义一些术语，以便在随后的讨论中使用。

●       工作空间(workspace)：资源的逻辑容器。这些资源可以被插件访问。

●       资源模型(resource model)：工作空间中可访问内容的逻辑表示。

●       项目(project)：工作空间中的管理模式；项目类似于文件夹，但并非与文件夹完全一样。

●       性质(nature)：一种把行为和功能与项目关联的方法。工具可以通过添加扩展来定义性质。

●       构建器(builder)：工作空间所使用的一种机制，它允许与工具相关的程序在特定的时间处理更改的文件。通常情况下，构建器用于实现资源在不同形式间的转换处理。工具可以通过添加扩展来定义自己的构建器。

●       标记(marker)：一种可以关联其他资源的抽象实体。Eclipse自身已经定义了一些可重用的标记类型；工具可以使用这些标记类型或者通过添加扩展来定义新的标记类型。

23.1.1  物理视图

工作空间在文件系统中以目录的形式存在。在使用Eclipse的时候，仅有一个工作空间是活动的。资源插件负责对加入到工作空间中的资源进行记录。另外，资源插件还负责允许工具对私有数据分别进行存储。这些私有数据来自于用户可见的资源。

在Navigator视图中，以下3种资源类型是可见的：

●       项目：文件和文件夹的集合。项目是工作空间的一部分，但并不一定要求项目物理存在于工作空间目录中。

●       文件夹：文件的容器。文件夹用于文件的组织和命名空间的管理，它包含于项目或者其他文件夹中。

●       文件：字节流。文件用于存储资源的持久状态。文件总是包含于文件夹或者项目中。

工作空间目录既可以在物理上包含项目，也可以对存在于文件系统其他位置的项目保持一个引用。Eclipse对项目位置所提供的这两种支持并不会对Eclipse的操作规则造成任何更改。因此，在本章余下部分，我们将忽略这一点。

下面示例所显示的是一个工作空间的目录结构。该工作空间包含一个项目(a_project)、一个文件夹(a_folder)和两个文件(a.file1，a.file2)。

/workspace/.metadata

/workspace/.metadata/.plugins/org.eclipse.core.resources

/workspace/.metadata/.plugins/org.eclipse.ui

/workspace/.metadata/.plugins/org.eclipse.team.core

/workspace/a_project

/workspace/a_project/.project

D:/workspace/a_project/a.fi1e1

D:/workspace/a_project/a_fo1der

D:/workspace/a_project/a_fo1der/a.fi1e2

.project文件并不是由用户添加到a_project目录中，而是由org.eclipse.core.resources插件创建的。该文件用于存储项目自身的信息。.project文件的内容可以通过文本编辑器查看，但不要直接对它进行修改。我们将在本章后续部分的“项目描述”一节中对.project文件作进一步讨论。

每个工作空间都包含一个.metadata目录，它用于存储私有数据。.metadata目录包含一个.plugins目录，用于存储每个插件的状态数据。但在上例所显示的.metadata条目中并没有列出每个插件状态目录中的文件。您看到的.metadata/.plugins下的状态目录和文件的实际数目取决于加载的插件和使用的Eclipse的功能。

插件通过Plugin.getStateLocation方法获取一个到其状态目录的引用。当插件存储状态数据时，会在 .metadata/.plugins目录下创建一个与插件同名的目录。我们可以在这个目录下找到与插件相关的资源。

不要直接修改.metadata目录的内容。然而，有时您可以通过浏览或搜索目录树在其中找到有用的信息。例如，状态目录中的dialog_settings.xml文件存储了由指定的插件所保存的对话框内容。

23.1.2  逻辑视图

资源模型远不止您在磁盘上所见到的内容。工作空间API中定义了一种类的层次结构；这些类代表了资源模型的核心，以及您在Navigator视图中所能看到的资源。如果将目光集中在这些资源上，您可以了解到如何使用逻辑图以及工作空间API的层次接口将资源模型映射到文件系统中。如图23-1所示。

 

图23-1  资源模型：逻辑视图和接口层次结构图

对于资源模型中的每个元素，工作空间API均有对应的接口，但是图23-1仅显示了那些直接在文件系统中表示的接口。这些接口允许您对资源进行操作，这些资源是您的用户可以在Navigator视图中实际看见的资源。

●       IResource是所有工作空间资源的通用接口。基本的资源操作由IResource接口提供，包括支持以工作空间API形式存在的其他服务。

●       IContainer接口由资源模型对象实现。这些资源模型对象可以包含其他对象。如层次结构图所示，这些对象包括工作空间根目录、项目和文件夹。IContainer接口允许您对容器的成员进行操作。

●       IFile接口对创建、删除和移动文件提供支持。访问和修改文件内容也同样由它支持。

●       IFolder接口对获取、创建、删除和移动等与文件夹相关的操作提供支持。

●       IProject接口对与项目相关的操作提供支持。这包括基本的创建、删除和移动，以及项目中其他可用的功能(描述、性质、构建器以及指向其他项目的引用)。

●       IWorkspaceRoot提供到工作空间中各项内容的入口。通过IWorkspaceRoot接口，您可以访问工作空间中的项目以及其他资源。您也可以从工作空间中获取工作空间根目录。

对于每种资源类型，工作空间API均包含对应的Java接口。

23.1.3  资源模型与文件系统的交互

您也许已经注意到工作空间一词在Eclipse环境中仿佛有两种含义。第一种含义简单地指本地文件系统中的目录，该目录包含了您在Navigator视图中可见的项目、文件夹和文件。第二种含义指工作空间“内容”在内存中的表示。作为Eclipse开发者，您应该理解资源模型，以便您不仅能够使用API进行一些常规的文件系统操作，比如复制、移动、创建和修改文件系统实体，而且能够借助API使用Eclipse特有的功能，比如持久属性和用于资源更改的事件通知。

当工作空间在Eclipse的启动过程中被激活时，保存的资源模型状态就被加载到内存中。图23-2以一个只含少量资源的工作空间为例显示了资源模型与文件系统之间的这种映射关系。

 

图23-2  资源模型和文件系统

所有由工作空间API引起的更改，例如向项目中添加文件夹或文件，都会立即反映到内存中的工作空间资源模型。在工作空间中创建一个新的资源，也会相应地存在于文件系统中。直接对文件系统进行的更改，例如使用命令行或操作系统用户界面将文件夹或文件复制到项目中，并不会被工作空间所感知，直到用户或者由工作空间API(Iresource.refreshLocal)执行一次刷新操作，这些更改才会反映到工作空间中。如果需要的话，用户可以让刷新操作自动执行。用户可以设置Workbench中的Refresh workspace automatically首选项，使得工作空间侦听文件系统的更改，并且作出相应的反应，以保持工作空间与文件系统之间的同步。

注意：

您最好不要依赖于所设置的自动刷新首选项，应该由用户来控制刷新。一种普遍的做法是，在直接修改文件系统后，刷新工作空间或者更好的做法是刷新特定的资源或资源树。当用户已经要求工作空间进行同步时，这样做，并不会产生什么坏处。但是您却可以知道是否需要首先执行refreshLocal。如下代码将有助于您确定当前的状态并作出相应的动作。

if (! ResourcesPlugin.getP1ugin().getPluginPreferences()

.getBoo1ean(ResourcesP1ugin.PREF_AUTO_REFRESH))

try {

project.refreshLocal(IResource.DEPTH_INFINITE, null);

} catch (CoreException e) {

e.printStackTrace();

}

如果您在本地保存了刷新设置，请一定要对文件系统的更改进行侦听。详细内容请参见第17章“对话框设置、首选项和用户设置”中的“对首选项值的更改作出反应”一节。

对工作空间进行刷新并不会添加项目；必须通过工作空间API来添加项目，以便它们成为工作空间的一部分。例如，在图23-2中，文件系统中有一个名为other_directory的目录，但在资源模型的图表中却没有相对应的项。

当Eclipse关闭时，也可以对文件系统进行更改。默认情况下，当Eclipse再次启动时，这些更改不会反映到工作空间中。您可以设置Refresh workspace at startup首选项来要求Eclipse每次启动时强制进行工作空间与文件系统的同步。

资源模型与文件系统之间的这种对应关系要求您在使用工作空间API时，要遵循一定的模式。您可以获取一个资源的引用，但是在对它进行修改之前，必须首先确定它存在于文件系统中，同样，在创建资源时，您也需要首先确定它尚未存在。我们将在下一节中对工作空间与文件系统的交互以及编程模式进行回顾。

23.1.4  Navigator视图中资源的可见性

默认情况下，工作空间中的资源在Eclipse平台的Navigator视图中是可见的。Navigator视图是一种资源访问和交互的通用视图。许多工具经常会创建它们自己的视图，其中某些视图还是Navigator视图的替代品(例如JDT的Package Explorer视图)。详细内容请参见第18章关于视图创建的部分。

随着用户不断与您的工具、项目或其他资源进行交互，可能会在工作空间中创建一些资源。您可能希望这些资源对于用户是隐藏的。假设这些资源在工作空间中，那么用户有权看见它们，并且如果项目是共享的，它们还会被添加到资源库中。但是您可能希望通过一开始就隐藏这些资源或者至少允许用户在Navigator视图中对它们进行隐藏，以避免混乱。您可以通过创建一个资源过滤器扩展，来筛选实际在Navigator视图中显示的资源。过滤机制由图23-3所示的Navigator Filters对话框来控制。

您可以使用org.eclipse.ui.ide.resourceFilters扩展点来添加一个新的过滤器，并且将这一扩展添加到您的插件中，同时指定过滤时所用的文件名模式。在下面的例子中，扩展名为.private的文件将从视图中过滤掉。由于属性selected的值为false，默认情况下该过滤器不会生效。

 

图23-3  Navigator Filters对话框

<extension

point="org.ec1ipse.ui.ide.resourceFi1ters">

<fi1ter

se1ected="fa1se"

pattern="*.private"/>

</extension>

这段代码向Navigator Filters对话框中添加了一个文件过滤模式，图23-3显示了添加后的结果。