今年九月下旬發布了OSGi 4.2規范，至今已經一個月有余。InfoQ的Alex Blewitt總結了這一個多月來的OSGi進展情況，應該說是一片大好，十分熱鬧。下面請看詳情：
51CTO編輯推薦：OSGi入門與實踐全攻略
今年初發布的Equinox 3.5實現了OSGi規范草案，而最近發布的apache Felix 2.0也提供了對OSGi 4.2的支持。除此之外，前幾天發布的Knopflerfish 3.0 beta除了框架加載器還在開發當中外已經實現了4.2核心。
兩周前發布的apache Karaf 1.0構建在核心框架之上，其目的在於形成一個獨立於引擎的OSGi框架，同時帶有幾個事先打好包的bundle，比如Blueprint、provisioning、日志、遠程訪問（通過SSH）等。對於那些OSGi新手來說，這是一個很好的起步點，因為它把所有東西都已經打好包了，就像是構建在標准Linux內核之上的Linux分發一樣，可以提供額外的特性和管理功能。
近日SpringSource（已經被VMware收購）發布了dm Server 2.0M5，該版本也為Blueprint服務提供了OSGi參考實現並使用了嵌套框架（nested framework）特性。該特性在OSGi 4.2意見征集時被提出來，但卻被擱置到未來版本中，OSGi框架可以利用該特性為特定的應用創建內部框架（在dm Server術語中叫做region）。這樣我們就可以在系統中安裝多個應用並將這些應用與其他框架隔離開來。從中獲得的經驗一定會為下一版本的OSGi鋪平道理.
近日Jetty 7.0發布了，它既能作為獨立的Java Web引擎，也可以嵌入到其他應用中（包括OSGi和傳統的Java）。Oracle也宣布了WebLogic路線圖，其中就包含了正在進行當中的基於OSGi的microService架構。最後，Sun開發的GlassFish服務器也發布了V3 PrevIEw，該版本也基於OSGi，大家可以下載使用。
OSGi企業專家組正致力於定義一套OSGi服務（比如解析JNDI和Web Servlet），同時也已經定義好了OSGi遠程服務，這部分內容已經成為4.2規范的組成部分了。專家組希望在明年初發布一個版本，但目前的情況是每個主流的應用服務器的運行時都基於OSGi。
OSGi系統的運行是件輕而易舉的事情，但構建卻不是那麼回事了。雖然像Ant之類的工具可以處理平的類路徑、公共包可視化之類的事情，但OSGi運行時提供了一個更加模塊化的類路徑（既包括運行時，也包括編譯期）。現有的構建方案如Eclipse PDE對於特定的用例（如構建Eclipse插件）沒什麼問題，但卻無法做到獨立於IDE或是客戶化的構建。目前其他的構建引擎（如基於Any/Ivy的Apache Sigil，其目標是不僅支持Eclipse，還要支持NetBeans下的OSGi開發）也取得了長足的進展。盡管還處在孵化期，但最近apache Sigil已經可以實現自我構建，今年底就將發布版本了。
現在Pax Construct已經成為基於Maven構建的不可或缺的手段，它聯合使用了bnd工具，而後者則被Felix maven bnd插件所用。甚至還有人想從Maven倉庫中構建Eclipse，這樣我們就可以創建基於Maven的OSGi bundle並使用基於Eclipse的bundle了。然而最初這只適合於一小撮項目，他們可以展示這類系統的好處和必要性。
與此同時，Eclipse正致力於與另一個項目進行協同構建，這次叫做B3。這麼做並不會改變Eclipse項目的構建方式，相反，其目標在於將當前的PDE構建與其他構建/部署系統如Buckminster和基於Hudson的構建系統聯合起來。
現在NetBeans仍然徘徊在OSGi之外，這是因為netisgo（為NetBeans提供了OSGi支持）仍處在開發當中。另一方面，IntelliJ 9.0預覽版於近日發布了，社區版與旗艦版（在社區版的基礎上提供了額外的插件）都提供了OSGi支持。
Eclipse 3.6 M2已經發布幾周了，它是Eclipse平台下一版本的裡程碑版本。其Equinox支持包含了OSGi EventAdmin，這在目前正在開發當中的OSGi平台的異步支持中得到了廣泛的應用（以前Equinox所提供的EventAdmin是個單獨下載的bundle，這意味著沒幾個人會使用到它；由於合並到了RCP中，默認情況下就可以使用它了，因此其使用的范圍也更加廣泛了）。Equinox 3.6 M2還為bundle提供了加載期編織的功能，這是通過在bundle加載期利用ASPectJ注入代碼實現的。除此之外，Equinox控制台也變成多會話的了，這樣多個用戶就可以同時連到遠程實例上了。
最近在工具領域中Eclipse E4 1.0M1異軍突起。Eclipse E4是Eclipse平台在JavaScript運行時（如Web浏覽器）上的一個分支，其關注點在於異步。Eclipse 3.x中的很多行為都是同步的，這意味著用戶的行為會阻塞界面的響應。為了支持遠程客戶端，Eclipse修改了行為以支持異步訪問，其計劃是在未來將這些內容融合進Eclipse 3.x當中。其所提供的一個特性就是在純Javascript中創建OSGi bundle，大家可以訪問E4/JavaScript wiki來了解它是如何借助於JSFramework和JSConstants對象進行工作的。我們期待著E4 1.0M1的發布。
未來6個月要召開不少大會，OSGi無疑將成為一個明星。首先就是下周的SpringOne America，屆時將公布Burton Group 2nd Annual OSGi的調查結果。接下來就是本月底的EclipseCon Summit Europe，然後就是下個月的QCon SF。明年1月份將召開OSGi DevCon London 2010，緊跟其後的是3月底的QCon London以及將於加利福尼亞舉行的EclipseCon 2010。
全球的OSGi用戶群在蓬勃發展著，最近由Tara Simpson of Instil Software在Paremus舉辦的OSGi in Anger 對電信系統中應用OSGi以確保遠程管理並提供服務的經驗進行了探討。後續的討論在酒吧進行（由Luminis贊助），收到了很好的效果。由SkillsMatter記錄的演示資料與視頻放在了會議主頁上。很多項目從貌似的模塊系統遷移到了OSGi上，這有助於發現遺漏的包；Jetty在遷移到Eclipse上也遇到了同樣的問題。一旦這些系統遷移到OSGi上人們就會覺得如果沒有OSGi的話，想要構建這些復雜系統將是一件多麼難的事情啊。
簡單模塊系統怎麼樣了呢？它的目標是為OSGi和Jigsaw創建一個共同點。雖然一開始是很有前途的，但就運行時空間到底應該成為一個平的類路徑（就像現在的Java）還是嵌套類路徑（就像OSGi和編譯路徑），人們眾說紛纭。未來的專家組也許可以解決這個問題，但現在似乎還遙遙無期。Neil Bartlett將在倫敦的大會上談到這個問題。
