6.4 Eclipse 4.0

必須不斷檢查架構以評估它是否仍然合適。它能夠融入新技術嗎？它是否鼓勵社群的成長？吸引新的貢獻者是否容易？在2007年末，Eclipse專案提交者決定這些問題的答案是否定的，他們著手設計Eclipse的新願景。與此同時，他們意識到有數千個Eclipse應用程式依賴於現有的API。 2008年底建立了一個孵化器技術專案，其中包含三個具體目標：簡化Eclipse程式設計模型，吸引新的提交者，並使平臺能夠利用基於Web的新技術，同時提供開放式架構。

             圖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應用程式生成的模型的示例。

            圖6.10：為示例4.x應用程式生成的模型

6.4.2 層疊樣式表樣式

Eclipse於2001年釋出，在富網際網路應用程式時代之前，可以通過CSS進行面板處理以提供不同的外觀和感覺。 Eclipse 4.0提供了使用樣式表輕鬆更改Eclipse應用程式外觀的功能。可以在org.eclipse.platform包的css資料夾中找到預設的CSS樣式表。

6.4.3 依賴注入

Eclipse擴充套件登錄檔和OSGi服務都是服務程式設計模型的示例。按照慣例，服務程式設計模型包含服務生產者和消費者。經紀人負責管理生產者和消費者之間的關係。 

                   圖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。

原文連結