Eclipse体系结构介绍（四）

6.4 Eclipse 4.0

必须不断检查架构以评估它是否仍然合适。它能够融入新技术吗？它是否鼓励社区的成长？吸引新的贡献者是否容易？在2007年末，Eclipse项目提交者决定这些问题的答案是否定的，他们着手设计Eclipse的新愿景。与此同时，他们意识到有数千个Eclipse应用程序依赖于现有的API。 2008年底创建了一个孵化器技术项目，其中包含三个具体目标：简化Eclipse编程模型，吸引新的提交者，并使平台能够利用基于Web的新技术，同时提供开放式架构。

[Eclipse 4.0 SDK Early Adopter Release]

图6.9：Eclipse 4.0 SDK早期采用者发布

Eclipse 4.0于2010年7月首次发布，供早期采用者提供反馈。它由作为3.6版本一部分的SDK软件包和从该技术项目毕业的新软件包组合而成。与3.0一样，有一个兼容层，因此现有的捆绑包可以与新版本一起使用。与往常一样，有一点需要注意，消费者需要使用公共API才能确保兼容性。如果您的捆绑包使用内部代码，则没有这样的保证。 4.0版本提供了Eclipse 4应用程序平台，它提供了以下功能。

6.4.1 模型工作台

在4.0中，使用Eclipse Modeling Framework（EMFgc）生成模型工作台。由于渲染器与模型对话然后生成SWT代码，因此模型与视图呈现之间存在关注点分离。默认设置是使用SWT渲染器，但也可以使用其他解决方案。如果创建示例4.x应用程序，则将为默认工作台模型创建XMI文件。可以修改模型，并立即更新工作台以反映模型中的更改。图6.10是为示例4.x应用程序生成的模型的示例。

[Model Generated for Example 4.x Application]

图6.10：为示例4.x应用程序生成的模型

6.4.2 层叠样式表样式

Eclipse于2001年发布，在富互联网应用程序时代之前，可以通过CSS进行皮肤处理以提供不同的外观和感觉。 Eclipse 4.0提供了使用样式表轻松更改Eclipse应用程序外观的功能。可以在org.eclipse.platform包的css文件夹中找到默认的CSS样式表。

6.4.3 依赖注入

Eclipse扩展注册表和OSGi服务都是服务编程模型的示例。按照惯例，服务编程模型包含服务生产者和消费者。经纪人负责管理生产者和消费者之间的关系。

[Relationship Between Producers and Consumers]

图6.11：生产者和消费者之间的关系

传统上，在Eclipse 3.4.x应用程序中，消费者需要知道实现的位置，并了解框架内的继承以消费服务。因此，消费者代码不太可重复使用，因为人们无法覆盖消费者接收的实现。例如，如果要在Eclipse 3.x中更新状态行上的消息，代码将如下所示：

getViewSite().getActionBars().getStatusLineManager().setMessage(msg);

Eclipse 3.6是根据组件构建的，但其中许多组件的耦合太紧密。为了组装更松散耦合组件的应用程序，Eclipse 4.0使用依赖注入为客户端提供服务。 Eclipse 4.x中的依赖注入是通过使用自定义框架来实现的，该框架使用上下文的概念，该上下文用作为消费者定位服务的通用机制。应用程序和框架之间存在上下文。上下文是分层的。如果上下文具有无法满足的请求，则它将请求委托给父上下文。 Eclipse上下文称为IEclipseContext，它存储可用的服务并提供OSGi服务查找。基本上，上下文类似于Java映射，因为它提供了名称或类到对象的映射。上下文处理模型元素和服务。模型的每个元素都有一个上下文。服务通过OSGi服务机制在4.x中发布。

上下文和应用程序之间的关注点分离允许更好地重用组件，并使消费者免于理解实现。在4.x中，更新状态行的代码如下所示：

@Inject
IStatusLineManager statusLine;
⋮    ⋮    ⋮
statusLine.setMessage(msg);

6.4.4 应用服务

Eclipse 4.0的主要目标之一是简化消费者的API，以便轻松实现公共服务。简单服务列表被称为“二十件事”，被称为Eclipse应用程序服务。目标是提供客户可以使用的独立API，而无需深入了解所有可用的API。它们被构造为单独的服务，因此它们也可以用于除Java以外的其他语言，例如Javascript。例如，有一个API可以访问应用程序模型，读取和修改首选项以及报告错误和警告。

6.5 结论

Eclipse的基于组件的体系结构已经发展到包含新技术，同时保持向后兼容性。这成本很高，但回报是Eclipse社区的增长，因为消费者可以继续基于稳定的API发布产品。

Eclipse拥有众多具有不同用例的消费者，新的消费者难以采用和理解我们庞大的API。回想起来，我们应该保持API更简单。如果80％的消费者仅使用20％的API，则需要简化，这是创建Eclipse 4.x流的原因之一。

人群的智慧确实揭示了有趣的用例，例如将IDE分解为可用于构建RCP应用程序的bundle。相反，群体通常会产生大量噪音，需要花费大量时间来实施边缘情况。

在Eclipse项目的早期阶段，提交者可以将大量时间用于文档，示例和回答社区问题。随着时间的推移，这个责任已转移到整个Eclipse社区。我们可以更好地提供文档和用例来帮助社区，但鉴于每个版本都计划了大量项目，这一点很难实现。与软件发布日期的预期相反，在Eclipse，我们始终按时交付我们的发布，这使我们的消费者可以相信他们也能够做到这一点。

通过采用新技术，重新发明Eclipse的外观和工作方式，我们继续与消费者进行对话，让他们参与社区活动。如果您有兴趣参与Eclipse，请访问http://www.eclipse.org。

原文链接