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