概述
Eclipse中最出彩的部分莫過于它的Plugin Framework，可以說Eclipse在一定程度上使得Plugin機制得以流行，當然，Eclipse的優(yōu)勢不僅僅在此，但正因為采用了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實現(xiàn)的依據(jù)，鑒于此就得簡單提提OSGI了，主要從Plugin的角度來分析OSGI，OSGI概念中主要分為了Bundle和Service，可以認為Bundle是一個模塊的管理器，主要是通過BundleActivator管理模塊的生命周期，而Service則是這個模塊可暴露對外的服務對象，這里體現(xiàn)了OSGI和傳統(tǒng)的Plugin Framework不同的一個地方，管理和靜態(tài)結構分開，在OSGI中通過在manifest.mf文件中增加一些內(nèi)容來發(fā)布Bundle，在其中描述了Bundle的提供商、版本、唯一ID、classpath、暴露對外的包、所依賴的包；每個Bundle擁有自己的ClassLoader以及context，通過context可進行服務的注冊、卸載等，這些操作都會通過事件機制廣播給相應的其他的Bundle；一般來說都為通過在Bundle中編寫初始需要注冊的服務的方法來完成Bundle可供外部使用的服務的暴露功能；如需要調(diào)用其他Plugin提供的服務可通過context的getServiceReference先獲取Service的句柄，再通過context.getService(ServiceReference)的方法獲取Service的實體。
Eclipse Plugin定義
Eclipse中的Plugin的概念為包含一系列服務的模塊即為一個Plugin。既然是遵循OSGI的，也就意味著Plugin通常是由Bundle和N多Service共同構成的，在此基礎上Eclipse認為Plugin之間通常存在兩種關系，一種為依賴，一種為擴展，對于依賴可通過OSGI中元描述信息里添加需要引用的Plugin即可實現(xiàn)，但擴展在OSGI中是沒有定義的，Eclipse采用了一個Extension Point的方式來實現(xiàn)Plugin的擴展功能。
結合OSGI
Eclipse遵循OSGI對于Plugin的ID、版本、提供商、classpath、所依賴的plugin以及可暴露對外的包均在manifest.mf文件中定義。
Plugin Extension Point
對于擴展，Eclipse采用Extension Point的方式來實現(xiàn)，每個Plugin可定義自己的Extension Point，同時也可實現(xiàn)其他Plugin的Extension Point，由于這個在OSGI中是未定義的，在Eclipse中仍然通過在plugin.xml中進行描述，描述的方法為通過<extension-point id="" name="" schema="">的形式來定義Plugin的擴展點，通過<extension point="">的形式來定義實現(xiàn)的其他Plugin的擴展點，所提供的擴展點通過schema的方式進行描述，詳細見eclipse extension-point schema規(guī)范，為了更好的說明擴展點這個概念，舉例如下，如工具欄就是工具欄Plugin提供的一個擴展點，其他的Plugin可通過此擴展點添加按鈕至工具欄中，并可相應的添加按鈕所對應的事件(當然，此事件必須實現(xiàn)工具欄Plugin此擴展點所要求的接口)，工具欄的Plugin將通過callback的方式來相應的響應按鈕的動作?？梢娡ㄟ^Extension Point的方式可以很好的提供Plugin的擴展方式以及實現(xiàn)擴展的方式。
Eclipse Plugin Framework
那么Eclipse是如何做到Plugin機制的實現(xiàn)的呢？？還是先講講Eclipse的設計風格，Eclipse在設計時有個重要的分層法則，即語言層相關和語言層無關的代碼分開(如jdt.core和core)，核心與UI分開(如workbench.ui和workbench.core)這兩個分層法則，這個在Eclipse代碼中處處可見，在Plugin Framework部分也充分得體現(xiàn)了這個，遵循OSGI，Eclipse首先是實現(xiàn)了一個OSGI Impl，這個主要通過它的FrameWork、BundleHost、ServiceRegistry、BundleContextImpl等對象來實現(xiàn)，如果關心的話大家可以看看這部分的代碼，實現(xiàn)了Bundle的安裝、觸發(fā)、卸載以及Service的注冊、卸載、調(diào)用，在Plugin機制上Eclipse采用的為lazy load的方式，即在調(diào)用時才進行實際的啟動，采用的為句柄/實體的方式來實現(xiàn)，外部則通過OSGI進行啟動、停止等動作，各Plugin則通過BundleContext來進行服務的注冊、卸載和調(diào)用，這是OSGI的部分實現(xiàn)的簡單介紹。
那么Extension Point方面Eclipse是如何實現(xiàn)的呢，在加載Plugin時，Eclipse通過對plugin.xml的解析獲取其中的<extension-point>節(jié)點和<extension>節(jié)點，并相應的注冊到ExtensionRegistry中，而各個提供擴展點的Plugin在提供擴展點的地方進行處理，如工具欄Plugin提供了工具欄的擴展點，那么在構成工具欄時Plugin將通過Platform.getPluginRegistry().getExtensionPoint(擴展點ID)的方法獲取所有實現(xiàn)此擴展點的集合IExtensionPoint[]，通過此集合可獲取IConfigurationElement[]，而通過這個就可以獲取<extension point="">其中的配置，同時還可通過IConfigurationElement創(chuàng)建回調(diào)對象的實例，通過這樣的方法Eclipse也就實現(xiàn)了對于Plugin的擴展以及擴展的功能的回調(diào)。在Plugin Framework中還涉及很多事件機制的使用，比如Framework的事件機制，以便在Bundle注冊、Service注冊的時候進行通知。
總結
通過對Eclipse啟動過程的分析，可清晰的看到Eclipse Kernel+Core Plugins+Application Plugins的方式，在代碼中分別對應為loadBasicBundles和registerApplicationServices，loadBasicBundles通過加載config.ini中的osgi.bundles完成基本的bundles的加載，去看看這個配置會發(fā)現(xiàn)是org.eclipse.core.runtime還有一個update，core.runtime又會通過IDEApplication來完成整個Eclipse的啟動，同時會注冊所有與workbench相關的plugin。
Eclipse由于以前版本的Plugin Framework是沒有采用OSGI的，所以通過EclipseAdaptor的方式來實現(xiàn)與以往的兼容，目前新的Plugin采用的方式基本就是manifest.mf描述Plugin OSGI部分的信息，Plugin.xml描述擴展點的信息。
Eclipse中有非常多優(yōu)秀的設計，這個在看它的代碼時會有很深的感觸，比如Contributing to Eclipse中提到的Extension Object/Interface的設計，確實是非常的不錯，雖然看到你可能覺得很簡單，關鍵是要想得到并合適的去使用。
總結陳詞，^_^，Eclipse Plugin Framework是采用OSGI Impl+Plugin Extension-Point的方式來共同實現(xiàn)的，實現(xiàn)了Plugin的部署、編寫、獨立的Classloader和Context、Plugin中Service的注冊、Plugin中Service的調(diào)用、Plugin的依賴、Plugin的擴展、Plugin生命周期的管理。
帶來的思考
Eclipse Plugin Framework采用的是OSGI的實現(xiàn)，一定程度上我們也能看到OSGI的優(yōu)點，那么JMX+IoC方式的Plugin Framework與其的比較又是在哪些方面呢？Eclipse Plugin Framework不足的地方又在哪里呢？哪些地方值得改進呢？
