對Eclipse擴展點進行編碼的評估有些冗長，而且很少能自我解釋。 最近，我開始忙于處理這個主題，我寫了一個小助手，目的是減少通用編程步驟的樣板代碼，同時增加開發(fā)指導(dǎo)和可讀性。

它原來是不容易找到一個表現(xiàn)的解決方案，其中所有的使用情況下，我可以從目前的項目中提取匹配。 因此，我認為分享我的發(fā)現(xiàn)并看看別人對它的看法是一個好主意。

Eclipse擴展點評估

考慮一個簡單的擴展點定義，該定義支持擴展的無限貢獻。 這些貢獻中的每一個都應(yīng)該提供Runnable實現(xiàn)來執(zhí)行某種操作：

通常的評估任務(wù)是檢索所有貢獻，創(chuàng)建可執(zhí)行擴展并調(diào)用以下每個擴展 ：

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分成較小的方法來闡明其職責，但該類也將填充更多的粘合代碼。 當我發(fā)現(xiàn)這些部分難以閱讀且難以編寫時，我正在思考一種流暢的界面方法，該方法應(yīng)指導(dǎo)開發(fā)人員完成各個實現(xiàn)步驟。

結(jié)合Java 8 lambda表達式，我可以創(chuàng)建一個輔助工具，將evaluate功能歸結(jié)為：

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

誠然，我作弊了一點，因為通過使用java 8 Collection#forEach功能而不是顯式循環(huán)，可以對第一個示例進行一些改進。 但是我認為這仍然不能使代碼真正出色！

有關(guān)如何使用擴展點機制擴展Eclipse的一般信息，您可以參考在線文檔的《 插件開發(fā)環(huán)境指南 》。

注冊表適配器

輔助實現(xiàn)的主要類是RegistryAdapter ，它封裝了系統(tǒng)的IExtensionRegistry實例，并提供了一組方法來定義針對特定擴展點應(yīng)執(zhí)行的操作 。 目前，適配器允許讀取貢獻配置或創(chuàng)建可執(zhí)行擴展。

如上所示，使用多個表示的方法對多個貢獻進行評估–為了精確評估一個貢獻元素，以單數(shù)表示的方法是合適的。 這意味著對特定運行的貢獻，你會用操作createExecutableExtension而不是createExecutableExtension s 。

根據(jù)選擇的操作，可以使用不同的配置選項。 由于流暢的API實施了一種語法以提高指導(dǎo)和編程安全性，因此這成為可能。 例如， readExtension操作不允許注冊ExecutableExtensionConfigurator ，因為這將是一個無效的組合。

withConfiguration方法允許在每個可執(zhí)行擴展名創(chuàng)建后對其進行配置或初始化。 但是，如上面的示例所示，它也可以用于直接調(diào)用可運行擴展。 由于createExecutableExtension(s)的類型安全實現(xiàn)，因此可以在lambda表達式中訪問擴展實例而無需強制轉(zhuǎn)換。

最后，方法process()執(zhí)行指定的操作，并在需要進一步處理的情況下返回所創(chuàng)建元素的類型化Collection ：

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

謂語

但是，如何通過適配器選擇單個蝕擴展點貢獻元素呢？ 假設(shè)我們在上面的貢獻定義中添加了一個屬性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 ，它提供一組預(yù)定義的實現(xiàn)，以簡化諸如屬性選擇之類的常見用例。 上面的代碼是使用靜態(tài)導(dǎo)入實現(xiàn)的快捷方式：

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

其中“ myContribution”代表擴展貢獻中聲明的唯一ID值：

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

當然，在預(yù)設(shè)不足的情況下，可以實現(xiàn)自定義謂詞：

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

延期

通常，Eclipse擴展點評估大部分時間在IConfigurationElement 。 適配器API在區(qū)分擴展點和配置元素方面不夠清晰，并提供了一個稱為Extension的簡單封裝。 但是對于更復(fù)雜的任務(wù)， Extension實例使基礎(chǔ)配置元素可訪問。

通常， Extension為屬性值，貢獻名稱，貢獻值，嵌套貢獻提供訪問器，并允許創(chuàng)建可執(zhí)行擴展。 引入此抽象的主要原因之一是擁有一個API，該API將檢查后的CoreException隱式轉(zhuǎn)換為運行時異常，因為我習(xí)慣于使用Fail Fast方法而無需進行大量檢查后的異常處理。

異常處理

但是，如果在插件啟動時調(diào)用Eclipse擴展評估或在后臺執(zhí)行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 }

注意，返回的貢獻集合當然只包含那些沒有遇到任何麻煩的元素。

在哪里得到的？

對于那些想要簽出的人，這里有一個P2存儲庫，其中包含com.codeaffine.eclipse.core.runtime功能，提供RegistryAdapter及其隨附的類。 該存儲庫位于：

• http://fappel.github.io/xiliary/

源代碼和問題跟蹤器托管在：

• https://github.com/fappel/xiliary

盡管此時文檔已完全丟失，但應(yīng)該很容易開始使用本文給出的說明。 但是請記住，這個小工具還處于早期狀態(tài)，可能會進行一些API更改。 特別是在循環(huán)貢獻時僅處理CoreException仍然有點太弱。

結(jié)論

以上各節(jié)介紹了RegistyAdapter的基本功能，并重點介紹了它如何簡化Eclipse擴展點評估。 我用適配器替換了當前項目中的舊實現(xiàn)，并且沒有遇到任何麻煩，這意味著到目前為止，該解決方案對我來說很有希望……

但是，除了眼神之外，還有更多。 有了這個小幫手，再加上其他自定義斷言類型，為擴展點的評估功能編寫集成測試確實很容易。

但是，該主題超出了本文的范圍，下一次將涉及該主題。 因此，請保持關(guān)注，不要忘記分享知識，以防您發(fā)現(xiàn)上述方法有用–謝謝！

翻譯自: https://www.javacodegeeks.com/2014/10/eclipse-extension-point-evaluation-made-easy.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的Eclipse扩展点评估变得容易的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。