e2帧结构_e4中的灵活项目结构

e2帧结构

IDE项目由一组组织好的文件及其元信息组成，这些文件及其元信息可用于完成特定任务（例如构建可执行文件）。

传统上，C / C ++ IDE项目从根本上讲是由分层记录的简单文件列表组成。 诸如Metrowerks CodeWarrior和Microsoft Visual Studio之类的C / C ++ IDE是使用这种方法处理项目的一个很好的例子。

但是Eclipse IDE最初旨在支持Java开发，因此其原始项目引擎具有不同的根源。

与基于C的语言相反，在Java中，java类与包含它们的源文件之间存在更紧密的集成。 为了使Java编译器能够找到类定义，源文件通常与它包含的公共类具有相同的名称，但是更重要的是，java类必须位于与文件系统目录同名的源文件中。他们的包裹名称。

javac的唯一灵活性是指定类路径指令，但这并没有减轻基本的限制，即必须根据包名称将Java源文件保留在目录中。

因此，对于Java开发人员而言，源文件的组织比基于C的语言要严格得多，在C语言中，查找源文件不是问题（所有源都必须显式传递给编译器），并且头文件要么相对于源文件本身，或相对于给定的包含路径。 C / C ++开发人员倾向于根据许多因素将源文件托管在一个复杂的目录网络中，这些因素包括发布工程，组件化，团队合作和开发历史。

由于目录/软件包名称的限制，Eclipse作为Java IDE不需要支持非常灵活的项目结构，并且在其早期发行版中，它仅显示磁盘上项目目录的直接表示形式。

这种设计很快就不足以将Eclipse用作更通用的工具IDE，因此多年来添加了许多功能，以使Eclipse项目具有更灵活的项目结构，例如链接的资源。

但是，即使在最新的Eclipse Platform版本（Galileo）中，当涉及处理位于项目目录之外的文件时，Eclipse项目文件管理仍然存在问题。

主要限制如下：

虚拟项目文件结构

Eclipse中现有的资源原语不能完全允许用户在项目中创建真正任意复杂的文件结构。 限制是，为了创建给定的层次结构，唯一可用的容器对象是文件夹和链接的资源文件夹。 不幸的是，两者都需要位于文件系统上的实际文件夹。 它们之间的唯一区别是工作空间树中的父项与文件系统中的父项是否相同。

为了减轻此限制，e4现在支持组。 组是在文件系统中没有位置的容器（由API视为普通的IFolder资源）。 因此，只能在一个组下创建链接的资源文件和文件夹。

组在资源导航器中显示为紫色文件夹，以区别于常规文件夹。

已将项目浏览器设置为可感知组的，因此可以以最适当的方式处理目标为组的项目浏览器中的常规拖放操作。 例如，当用户将普通文件资源拖放到组上时，不是简单地给出错误，而是自动创建指向原始文件的链接资源。

可移植性

在项目中记录文件列表时的第一个要求是，必须以可跨计算机移植的方式记录文件的位置。

在Galileo之前，记录链接资源的机制依赖于工作空间级别的变量列表，并且用户指定了相对链接资源的位置。 因为此变量列表与大量用户设置一起保存在工作区.metadata文件夹中，所以在项目中使用链接资源实际上使该项目无法跨计算机甚至跨同一台计算机的工作区进行移植。

在e4中，项目现在将自己的路径变量列表存储在.project文件中。 项目“属性”中提供了一个新的属性页，允许用户查看和编辑路径变量。 默认路径变量可用于所有项目，包括PROJECT_LOC，该项目会自动初始化为项目目录位置。

第三方插件还可以通过variableProviders core.resources扩展点扩展默认项目路径变量列表。

使用方便

在Eclipse中使用链接资源的主要障碍之一是创建链接资源的繁琐过程，这需要用户经历新的文件/文件夹向导，并一一创建链接资源。 每次指定位置。

在e4中，用户现在只需将其从OS Shell（即Windows资源管理器）拖放到工作台项目资源管理器中，就可以创建链接的资源。 然后出现一个对话框，让用户选择应创建哪种类型的资源。

首选包括遗留的Eclipse行为：将所有文件复制到目标位置下。 第二种选择允许用户自动创建组和链接的资源文件的层次结构，从而模仿文件系统层次结构。

第三个将仅为拖动源中包含的每个文件和文件夹生成链接资源，而不创建任何组。

创建链接资源后，用户可以允许Eclipse自动生成相对于最合适的变量（通常是PROJECT_LOC）的位置，或显式选择应在其中创建链接资源位置的变量。

管理

为了使链接资源成为Eclipse中的一流工作流，已经进行了许多更改。 这些更改之一是允许用户从资源属性页面更改链接资源的位置。

另一个改进是项目属性页面中的“链接资源”编辑器，用户可以在该位置方便地查看所有项目的链接资源，并按位置错误状态分组。 在这里，链接的资源位置可以自动转换，创建变量和更改位置。

可扩展性

e4中的另一个新功能是资源过滤器。

资源过滤器允许用户配置在执行refreshLocal（）时，哪些文件系统资源对Eclipse工作区树可见。 用户可以创建仅包含过滤器，排除所有过滤器，并指定这些过滤器是否适用于文件，文件夹或两者。 它们也可以设置为可继承的，因此给定容器的所有子代将自动继承过滤器。

筛选器在core.resource API的最低级别上运行，因此资源可以存在于包含成千上万个文件的文件系统层次结构中，而不会增加core.resource插件的工作量和内存开销。

只有通过刷新机制隐式填充在工作区树中的普通文件和文件夹资源才受到资源过滤器的约束。 由于用户显式创建链接的资源和组，因此资源过滤器不适用于它们。

可以在组资源上指定资源过滤器，但是它们仅在设置为可继承的范围内才有效，并且仅适用于在资源文件夹中链接的组的子级。

还可以在创建容器之前在容器上指定资源过滤器（在新资源向导中或以编程方式），以便可以适当地过滤初始的refresh（）。

也可以通过filtersProviders core.resources扩展点添加新的过滤器类型。

向后兼容

所有新的e4功能都与现有的Eclipse 3.x API合同完全兼容。 所有使用现有core.resources API的插件都将在使用新e4功能（包括组，项目路径变量和资源过滤器）的工作空间和项目中透明地工作。

唯一的细微差别是，插件将组视为链接的资源文件夹，当调用IResource.getLocation（）和IResource.getLocationURI（）时，它们始终返回null。

由于这已经是这些API的有效返回值，因此，如果3.x插件已正确处理了此值，则它将在e4中透明地工作。

未来的改进

core.resources中仍在讨论许多改进，包括自动项目供应，使用链接资源进行项目参考检修，序列化.project文件时的性能改进等…

使用新的链接资源API

可以想象，如果在Eclipse 1.0中提供了e4 core.resources功能，那么许多IDE功能将以不同的方式实现。

例如，JDT Java构建路径/库功能复制了许多基本链接资源功能以查找.jar文件，并且可以想象这将以不同的方式实现。

同样，e4全面而灵活的API集用于管理项目资源，拓宽了可以成功使用core.resource API的领域。

翻译自: https://jaxenter.com/flexible-project-structure-in-e4-100587.html

e2帧结构