概述
Eclipse中最出彩的部分莫過于它的Plugin Framework,可以說Eclipse在一定程度上使得Plugin機制得以流行,當然,Eclipse的優勢不僅僅在此,但正因為采用了Plugin機制,Eclipse才得以被不斷的擴充,越來越強大。一直以來就想分析Eclipse的Plugin Framework,由于各種原因一直耽擱,剛好這個周末沒什么事,下定決心對其進行了研究和分析,方法很原始,就是對Eclipse的啟動過程進行分析,基于的是Eclipse 3.1的版本,分析過程就不在這說了,主要是說說分析出來的心得。
架構上來講Eclipse基本采用的是Kernel+Core Plugins+Custom Plugins的結構體系,除了Kernel部分外均為Plugin,所以可稱為all are plugins,凡是Plugin的部分都是可被替換的。
OSGI
Eclipse 3.0后采用的是OSGI來作為其Plugin Architecture實現的依據,鑒于此就得簡單提提OSGI了,主要從Plugin的角度來分析OSGI,OSGI概念中主要分為了Bundle和Service,可以認為Bundle是一個模塊的管理器,主要是通過BundleActivator管理模塊的生命周期,而Service則是這個模塊可暴露對外的服務對象,這里體現了OSGI和傳統的Plugin Framework不同的一個地方,管理和靜態結構分開,在OSGI中通過在manifest.mf文件中增加一些內容來發布Bundle,在其中描述了Bundle的提供商、版本、唯一ID、classpath、暴露對外的包、所依賴的包;每個Bundle擁有自己的ClassLoader以及context,通過context可進行服務的注冊、卸載等,這些操作都會通過事件機制廣播給相應的其他的Bundle;一般來說都為通過在Bundle中編寫初始需要注冊的服務的方法來完成Bundle可供外部使用的服務的暴露功能;如需要調用其他Plugin提供的服務可通過context的getServiceReference先獲取Service的句柄,再通過context.getService(ServiceReference)的方法獲取Service的實體。
Eclipse Plugin定義
Eclipse中的Plugin的概念為包含一系列服務的模塊即為一個Plugin。既然是遵循OSGI的,也就意味著Plugin通常是由Bundle和N多Service共同構成的,在此基礎上Eclipse認為Plugin之間通常存在兩種關系,一種為依賴,一種為擴展,對于依賴可通過OSGI中元描述信息里添加需要引用的Plugin即可實現,但擴展在OSGI中是沒有定義的,Eclipse采用了一個Extension Point的方式來實現Plugin的擴展功能。
結合OSGI
Eclipse遵循OSGI對于Plugin的ID、版本、提供商、classpath、所依賴的plugin以及可暴露對外的包均在manifest.mf文件中定義。
Plugin Extension Point
對于擴展,Eclipse采用Extension Point的方式來實現,每個Plugin可定義自己的Extension Point,同時也可實現其他Plugin的Extension Point,由于這個在OSGI中是未定義的,在Eclipse中仍然通過在plugin.xml中進行描述,描述的方法為通過<extension-point id="" name="" schema="">的形式來定義Plugin的擴展點,通過<extension point="">的形式來定義實現的其他Plugin的擴展點,所提供的擴展點通過schema的方式進行描述,詳細見eclipse extension-point schema規范,為了更好的說明擴展點這個概念,舉例如下,如工具欄就是工具欄Plugin提供的一個擴展點,其他的Plugin可通過此擴展點添加按鈕至工具欄中,并可相應的添加按鈕所對應的事件(當然,此事件必須實現工具欄Plugin此擴展點所要求的接口),工具欄的Plugin將通過callback的方式來相應的響應按鈕的動作。可見通過Extension Point的方式可以很好的提供Plugin的擴展方式以及實現擴展的方式。
Eclipse Plugin Framework
那么Eclipse是如何做到Plugin機制的實現的呢??還是先講講Eclipse的設計風格,Eclipse在設計時有個重要的分層法則,即語言層相關和語言層無關的代碼分開(如jdt.core和core),核心與UI分開(如workbench.ui和workbench.core)這兩個分層法則,這個在Eclipse代碼中處處可見,在Plugin Framework部分也充分得體現了這個,遵循OSGI,Eclipse首先是實現了一個OSGI Impl,這個主要通過它的FrameWork、BundleHost、ServiceRegistry、BundleContextImpl等對象來實現,如果關心的話大家可以看看這部分的代碼,實現了Bundle的安裝、觸發、卸載以及Service的注冊、卸載、調用,在Plugin機制上Eclipse采用的為lazy load的方式,即在調用時才進行實際的啟動,采用的為句柄/實體的方式來實現,外部則通過OSGI進行啟動、停止等動作,各Plugin則通過BundleContext來進行服務的注冊、卸載和調用,這是OSGI的部分實現的簡單介紹。
那么Extension Point方面Eclipse是如何實現的呢,在加載Plugin時,Eclipse通過對plugin.xml的解析獲取其中的<extension-point>節點和<extension>節點,并相應的注冊到ExtensionRegistry中,而各個提供擴展點的Plugin在提供擴展點的地方進行處理,如工具欄Plugin提供了工具欄的擴展點,那么在構成工具欄時Plugin將通過Platform.getPluginRegistry().getExtensionPoint(擴展點ID)的方法獲取所有實現此擴展點的集合IExtensionPoint[],通過此集合可獲取IConfigurationElement[],而通過這個就可以獲取<extension point="">其中的配置,同時還可通過IConfigurationElement創建回調對象的實例,通過這樣的方法Eclipse也就實現了對于Plugin的擴展以及擴展的功能的回調。在Plugin Framework中還涉及很多事件機制的使用,比如Framework的事件機制,以便在Bundle注冊、Service注冊的時候進行通知。
總結
通過對Eclipse啟動過程的分析,可清晰的看到Eclipse Kernel+Core Plugins+Application Plugins的方式,在代碼中分別對應為loadBasicBundles和registerApplicationServices,loadBasicBundles通過加載config.ini中的osgi.bundles完成基本的bundles的加載,去看看這個配置會發現是org.eclipse.core.runtime還有一個update,core.runtime又會通過IDEApplication來完成整個Eclipse的啟動,同時會注冊所有與workbench相關的plugin。
Eclipse由于以前版本的Plugin Framework是沒有采用OSGI的,所以通過EclipseAdaptor的方式來實現與以往的兼容,目前新的Plugin采用的方式基本就是manifest.mf描述Plugin OSGI部分的信息,Plugin.xml描述擴展點的信息。
Eclipse中有非常多優秀的設計,這個在看它的代碼時會有很深的感觸,比如Contributing to Eclipse中提到的Extension Object/Interface的設計,確實是非常的不錯,雖然看到你可能覺得很簡單,關鍵是要想得到并合適的去使用。
總結陳詞,^_^,Eclipse Plugin Framework是采用OSGI Impl+Plugin Extension-Point的方式來共同實現的,實現了Plugin的部署、編寫、獨立的Classloader和Context、Plugin中Service的注冊、Plugin中Service的調用、Plugin的依賴、Plugin的擴展、Plugin生命周期的管理。
帶來的思考
Eclipse Plugin Framework采用的是OSGI的實現,一定程度上我們也能看到OSGI的優點,那么JMX+IoC方式的Plugin Framework與其的比較又是在哪些方面呢?Eclipse Plugin Framework不足的地方又在哪里呢?哪些地方值得改進呢?
前幾天忙著排練小品《大話讀研》,是在迎新晚會上演出的,自己覺得自己蠻投入的,也可以看得出來,我們這個劇組的其他成員也都很投入,當然演出效果也比較令人滿意,至少觀眾反映還是不錯的,著實令人欣慰。不過,參加這個劇組,卻讓我體會到了另外一種感覺,那就是團隊合作的精神,其實我覺著在這方面,我們現在很多人都存在著不足,但是很多人卻沒有意識到,而這次的合作,讓我對團隊精神有了新的理解,首先要有團隊意識,比如開會,你要想著不能遲到,因為如果你遲到,等待你的將是整個團隊,你浪費了所有人的時間,所以要心有團隊。其次,團隊說白了其實就是由很多人組成的,所以你必須同團隊里的每個人交互,有時需要保留個人意見,有時需要及時糾正別人的做法,也就是說團隊最后的走向取決于大家的合力,如果一個團隊里面大多數人都很消極或者說做錯了,那么可想而知這個團隊的結果是什么了,要么解散,要么演出失敗。最后一點團隊需要一個有力的“領導”,我這里對領導加引號,是因為我并不是說領導代表一種權利,高人一等,隨便發號施令,我認為領導在團隊中的作用是協調、溝通,在團隊中存在爭議時,能迅速解決爭議,使的團隊的進步不因個人的問題而停止或中斷,另外對團隊領導的要求就是要有計劃,有合理的安排,使得每個人能夠盡量獨立的發揮自己的聰明才干。
與此同時,我又參加了整場晚會的場地負責工作,包括預定場地、入場檢票、分發食品、頒獎、音樂控制等。由于缺乏經驗加之沒有計劃好,晚會剛開始的時候,場地一片混亂,入場處擁擠不堪,音樂控制處找不到伴奏帶等,我是又忙又急,還好在大家的集體努力下,很快扭轉了局面,也使我再一次感受到了團隊的力量。
總結起來,這次晚會之所以出現開場時的混亂局面,我認為有以下幾個原因:
1、 我們工作人員入場太晚,而這又是因為我們跟場地預定處沒協調好
2、 食品與獎品等運到現場也太晚,直接導致了入場檢票一度無法做,以及音樂控制處在等節目單和伴奏帶
3、 整體沒有配合好,比如場地如何布置,沒有人告訴我們該如何安排,導致后來節目快開始的時候又重新安排
這又使我想起莉莉(偶GF)的一句常說的話,“凡事盡量提前準備好”,不錯,這次我們就是在沒有提前準備好,導致了現場的混亂。
對于我個人來說,這的確是第一次負責這種工作,所以沒有什么經驗,對于突發情況的處理顯得手足無措,但同時也給我一次鍛煉的機會,雖然當時說了很多抱怨的話,但其實我還是不后悔負責這個工作,因為它讓我領會到一個小小的活動,想要把它搞好,也并不是很容易的。“麻雀雖小,五臟具全”嘛!
脫離了自己有些厭倦的工作環境,來到了自己心儀已久的南大,并如愿進入了自己喜歡的專業,似乎生活應該一下子美好了,可是,事實并非如此...
除了剛開始的幾天新鮮之外,接下來感覺自己又進入了另外一個循環,是的,只不過是跟以前的那個循環內容不同而已,但本質上還是一個循環。它有好的一面,說明我已經融入了這個環境,可是它也同時讓自己覺得跟以前的生活沒什么差別,唉,我于是感嘆,生活就是這樣,一山望著一山高,可是等你爬上去之后,發現也不過如此,有人說,正是人的這種不滿足才推動了世界的發展,或許吧。但是我想說的是,人很容易在這種每天周而復始的循環中迷失自己,現在自己已經很少思考了,特別是對自己正在做什么,將來要做什么,這些問題考慮的越來越少了,每天干著自己也不知道為什么要做的事,但是又覺著是理所當然要做的事,可是等哪天突然想起來的時候,就覺著很后悔,正所謂驀然回首,自己應該做的事居然都還沒做,于是我就問自己,那我做了什么呢?于是我茫然了,除了每天例行的吃喝拉撒,似乎就是泡在實驗室,在我慶幸自己能有個像實驗室這種棲身之所的時候,卻不知有多少寶貴的時間也就在這里毫無價值的流失...
于是我恍然,記得新東方的渝敏洪先生曾經到我們學校做過一個報告,我有幸得以一睹這位傳說中的人物,他的一句話讓我記憶憂新,他說,每天晚上睡覺前,他都會問自己,今天我做了什么有意義的事,如果實在想不起來有什么讓自己能記起的事,他就會拿出字典來背上幾個單詞,然后他會問自己我明天準備做什么。我想渝先生的這個習慣正是要監督自己,不讓自己每天虛度光陰,而是要把握屬于自己的每一分鐘,更不能讓無所事事來蠶食每天的光陰。
古人云:“見賢思齊焉,見不賢而內自省焉”,向渝先生學習一下怎么來把握自己的每一天吧!畢竟生活就是每一天!