Eclipse扩展点评估变得容易

对Eclipse扩展点进行编码的评估有些冗长，而且很少能自我解释。最近，我开始忙于处理这个主题，我写了一个小助手，目的是减少通用编程步骤的样板代码，同时增加开发指导和可读性。

它原来是不容易找到一个表现的解决方案，其中所有的使用情况下，我可以从目前的项目中提取匹配。因此，我认为分享我的发现并看看别人对它的看法是一个好主意。

Eclipse扩展点评估

考虑一个简单的扩展点定义，该定义支持扩展的无限贡献。这些贡献中的每一个都应该提供Runnable实现来执行某种操作：

扩展点定义

通常的评估任务是检索所有贡献，创建可执行扩展并调用以下每个扩展：

public class ContributionEvaluation {private static final String EP_ID= "com.codeaffine.post.contribution";public void evaluate() {IExtensionRegistry registry = Platform.getExtensionRegistry();IConfigurationElement[] elements= registry.getConfigurationElementsFor( EP_ID );Collection<Runnable> contributions = new ArrayList<Runnable>();for( IConfigurationElement element : elements ) {Object extension;try {extension = element.createExecutableExtension( "class" );} catch( CoreException e ) {throw new RuntimeException( e );}contributions.add( ( Runnable )extension );}for( Runnable runnable : contributions ) {runnable.run();}}
}

尽管可以将evaluate分成较小的方法来阐明其职责，但该类也将填充更多的粘合代码。当我发现这些部分难以阅读且难以编写时，我正在思考一种流畅的界面方法，该方法应指导开发人员完成各个实现步骤。

结合Java 8 lambda表达式，我可以创建一个辅助工具，将evaluate功能归结为：

public void evaluate() {new RegistryAdapter().createExecutableExtensions( EP_ID, Runnable.class ).withConfiguration( ( runnable, extension ) -> runnable.run() ).process();
}

诚然，我作弊了一点，因为通过使用java 8 Collection#forEach功能而不是显式循环，可以对第一个示例进行一些改进。但是我认为这仍然不能使代码真正出色！

有关如何使用扩展点机制扩展Eclipse的一般信息，您可以参考在线文档的《插件开发环境指南》。

注册表适配器

辅助实现的主要类是RegistryAdapter ，它封装了系统的IExtensionRegistry实例，并提供了一组方法来定义针对特定扩展点应执行的操作。目前，适配器允许读取贡献配置或创建可执行扩展。

如上所示，使用多个表示的方法对多个贡献进行评估–为了精确评估一个贡献元素，以单数表示的方法是合适的。这意味着对特定运行的贡献，你会用操作createExecutableExtension而不是createExecutableExtension s 。

根据选择的操作，可以使用不同的配置选项。由于流畅的API实施了一种语法以提高指导和编程安全性，因此这成为可能。例如， readExtension操作不允许注册ExecutableExtensionConfigurator ，因为这将是一个无效的组合。

withConfiguration方法允许在每个可执行扩展名创建后对其进行配置或初始化。但是，如上面的示例所示，它也可以用于直接调用可运行扩展。由于createExecutableExtension(s)的类型安全实现，因此可以在lambda表达式中访问扩展实例而无需强制转换。

最后，方法process()执行指定的操作，并在需要进一步处理的情况下返回所创建元素的类型化Collection ：

Collection<Extension> extensions= new RegistryAdapter().readExtensions( EP_ID ).process();

谓语

但是，如何通过适配器选择单个蚀扩展点贡献元素呢？假设我们在上面的贡献定义中添加了一个属性ID 。 RegistryAdapter的流利API允许指定可用于选择特定贡献的Predicate ：

public void evaluate() {new RegistryAdapter().createExecutableExtension( EP_ID, Runnable.class ).withConfiguration( ( runnable, extension ) -> runnable.run() ).thatMatches( attribute( "id", "myContribution" ) ).process();
}

有一个实用程序类Predicates ，它提供一组预定义的实现，以简化诸如属性选择之类的常见用例。上面的代码是使用静态导入实现的快捷方式：

.thatMatches( Predicates.attribute( "id", "myContribution" ) )

其中“ myContribution”代表扩展贡献中声明的唯一ID值：

<extension point="com.codeaffine.post.contribution"><contribution id="myContribution" class="com.codeaffine.post.MyContribution"></contribution>
</extension>

当然，在预设不足的情况下，可以实现自定义谓词：

public void evaluate() {Collection<Extension> extensions = new RegistryAdapter().readExtensions( EP_ID, Description.class ).thatMatches( (extension) -> extension.getValue() != null ).process();
}

延期

通常，Eclipse扩展点评估大部分时间在IConfigurationElement 。适配器API在区分扩展点和配置元素方面不够清晰，并提供了一个称为Extension的简单封装。但是对于更复杂的任务， Extension实例使基础配置元素可访问。

通常， Extension为属性值，贡献名称，贡献值，嵌套贡献提供访问器，并允许创建可执行扩展。引入此抽象的主要原因之一是拥有一个API，该API将检查后的CoreException隐式转换为运行时异常，因为我习惯于使用Fail Fast方法而无需进行大量检查后的异常处理。

异常处理

但是，如果在插件启动时调用Eclipse扩展评估或在后台执行Eclipse扩展评估，则不能选择“快速失败”。并且，在特定贡献引起问题之后，忽略剩余的贡献肯定是不合理的。因此，适配器API允许使用显式异常处理替换Fail Fast机制：

public void evaluate() {Collection<Runnable> contributions = new RegistryAdapter().createExecutableExtensions( EP_ID, Runnable.class ).withExceptionHandler( (cause) -> handle( cause ) ).process();[...]
}private void handle( CoreException cause ) {// do what you gotta do
}

注意，返回的贡献集合当然只包含那些没有遇到任何麻烦的元素。