卷1：第6章 Eclipse之三
6.4 Eclipse 4.0
架構必須持續(xù)地進行檢查以評估其是否依然合適。它是否能引入新的技術？它是否能帶動社區(qū)的成長？它是否便于吸收新的提交者？在2007年底，Eclipse項目確定這些問題的答案是否定的所以他們著手設計新版本的Eclipse。同時，他們意識到有成千上萬個Eclipse項目依賴于已有的API。在2008年的時候，他們創(chuàng)建了一個新的孵化項目，這個項目有三個明確的目標：通過開放式的架構來簡化Eclipse開發(fā)模型、吸引新的開發(fā)者以及利用基于web技術的優(yōu)勢。
布于2010年7月，它針對于早期試用者以獲取反饋信息。它的SDK包含兩部分的bundle，一部分來源于3.6釋放版，還有一部分新的bundle來源于技術項目。像3.0一樣，有一個兼容層以保證現(xiàn)存的bundle在新版本中依然可用。一如既往的是，要警告用戶為了保證兼容性需要使用公開的API。如果你的bundle使用了內(nèi)部代碼，將無法保證兼容性。4.0版本提供的Eclipse 4應用平臺提供了如下的特性：/p
pstrong6.4.1 模型工作臺/strong/p
p在4.0版本中，提供了一個模型工作臺，它使用了Eclipse模型框架（Eclipse Modeling Framework，EMFgc）。鑒于渲染器需要與模型交互并生成SWT代碼，有必要在模型和渲染視圖之間進行關注點的分離。默認會使用SWT渲染器，但是其它的方案也是可行的。如果你創(chuàng)建了一個4.x的示例應用，會為默認的渲染模型創(chuàng)建一個XMI文件。模型可以進行修改，而工作臺會隨著模型的變化即時更新。圖6.10是4.0的一個示例應用所生成的模型。/p
pimg src=)
圖6.10 4.0示例應用生成的模型
6.4.2級聯(lián)樣式表樣式
Eclipse發(fā)布于2001年，早于富互聯(lián)網(wǎng)應用的時代，在這個時代可以使用CSS來實現(xiàn)皮膚的切換以提供不同的外觀和體驗。Eclipse4.0提供了使用樣式表來容易地修改Eclipse應用外觀和體驗的功能。默認的CSS樣式單可以在org.eclipse.platform bundle的css文件下找到。
6.4.3 依賴注入
Eclipse的擴展注冊器和OSGi服務都是基于服務模型編程的。按照慣例，服務編程模型包含服務的生產(chǎn)者和消費者。而居間者（broker）負責管理生產(chǎn)者和消費者的關系。
者和消費者的關系/p
p在傳統(tǒng)的Eclipse3.4.x應用中，消費者需要了解為了使用服務需要了解實現(xiàn)類的位置并理解其在框架中的繼承關系。這樣消費者的代碼可重用性就降低了因為不能重寫消費者所能接受到的服務。例如，如果你想在Eclipse 3.x中更新狀態(tài)欄中的信息，代碼應該是這樣的：/p
precode getViewSite().getBars().getStatusLineManager().setMessage(msg);/code/pre
pEclipse 3.6是基于組件構建的，但是很多的組件耦合性很高。為了能夠耦合更寬松的組件來組建應用，Eclipse4.0使用了依賴注入來為客戶端提供給服務。Eclipse4.x中的依賴注入是通過使用一個自定義的框架來實現(xiàn)的，這個框架使用了上下文的理念來提供一個通用的機制來為消費者定位服務。上下文存在于應用和框架之間。上下文是有等級的。如果一個上下文的請求不能得到滿足，它將會把這個請求委托給父上下文。Eclipse的上下文，名為IEclipseContext，存儲了可用的服務并提供了OSGi服務的查找。簡單來說，上下文類似于一個Java的map，里面提供了一個名字或類與對象之間的映射。上下文處理模型元素和服務。每個模型元素都有一個上下文。在Eclipse 4.x中，服務是以OSGi服務的機制進行發(fā)布的。/p
pimg src=)
圖 6.12 服務居間者上下文（Service Broker Context）
生產(chǎn)者將服務和對象添加到上下文中儲存。通過上下文，服務被注冊到消費者對象中。消費者生命需要的服務而上下文負責確定如何滿足這個需求。這種方式使得使用動態(tài)服務更容易了。在Eclipse 3.x中，消費者需要注冊監(jiān)聽器，當服務可用或不可用的時候獲取通知。在Eclipse 4.x中，一旦一個上下文注入到消費者對象中，任何變化都會自動傳遞到那個對象中。換句話說，依賴注入會再次發(fā)生。消費者通過使用Java 5的注解來聲明使用上下文，這些注解是符合JSR 330規(guī)范的如@inject，除此以外還會有一些自定義的Eclipse注解。構造器、方法以及域注入都是支持的。4.x的運行環(huán)境會掃描對象來尋找這些注解。實際執(zhí)行的操作取決于使用的注解。
分離上下文和應用使得組件能夠更好地常用，也使得服務的消費者免于理解內(nèi)部實現(xiàn)。在4.x中，更新狀態(tài)行的代碼如下：
@Inject
IStatusLineManager statusLine;
? ? ?
statusLine.setMessage(msg);6.4.4 應用服務
Eclipse 4.0的一個主要目標是簡化用戶使用的API以便于其實現(xiàn)通用的服務。簡單的服務列表被稱為“20件事”（the twenty things）或Eclipse應用服務。其目標是為用戶提供單獨的API使得用戶不必深入了解所有的API。它們被組織成獨立的服務，因此可以用于其它非Java語言，像JavaScript。例如，有這樣的API可以訪問應用模型，讀取和修改首選項以及報告錯誤和警告。
6.5 結論
基于組件化架構的Eclipse可以不斷吸收新的技術而同時保證向后的兼容性。這樣的成本比較高昂，但是回報在于Eclipse社區(qū)在不斷發(fā)展壯大，因為用戶能夠基于建立起來的信任，不斷使用這些穩(wěn)定的API開發(fā)產(chǎn)品。 Eclipse廣大的用戶群體會有不同的使用場景而我們眾多的API使得新的用戶很難適應和理解。回顧過去，我們應該讓API更簡單一些。如果80%的用戶只使用20%的API，有必要對其進行簡化，這也是Eclipse 4.x創(chuàng)建的原因之一。
聰明的用戶群體帶來了有趣的使用場景，例如分解出IDE中的bundle來構建RCP應用。另一方面，群體有時候也會創(chuàng)造一些噪音來要求實現(xiàn)很少見的場景，這消耗了大量的時間來實現(xiàn)。
在Eclipse項目的早期，提交者有充裕的時間來編寫文檔、樣例以及回答社區(qū)的問題。隨著時間的推移，這個任務轉移給了整個Eclipse社區(qū)。我們本可以提供更好地文檔和樣例來幫助社區(qū)，但是因為每個釋放版本都會有大量的特性使得這變得很困難。一般情況下，軟件發(fā)布總是會延期；然而在Eclipse，我們總是按期發(fā)布，這樣做同時也可以幫助我們的客戶建立起按期發(fā)布產(chǎn)品的信心。
通過吸收新技術以及重新改造Eclipse的外觀和運行機制，我們會持續(xù)與用戶進行交流并使他們留在我們的社區(qū)。如果你對Eclipse相關信息感興趣，請訪問http://www.eclipse.org。
腳注
更多建議：