Equinox，我不想多做介紹，相信很多人都有所了解了，不了解的可具體去www.eclipse.org/equinox看看。
最近基于equinox做了一個系統，還是碰到了一些問題，當然也得到了在插件體系架構下的不少優(yōu)點，在這里也做個總結。
總體而言，基于equinox做開發(fā)對于大多數java開發(fā)人員來說應該不會有太多改變的感覺，最多改變的感覺應該是帶給設計師，設計師需要有發(fā)揮插件體系架構優(yōu)點以及減少其帶來的缺點的能力，^_^
1、部署不是很方便
equinox默認提供的是一個console端的插件部署管理，部署起來需要通過"install reference:file://"這樣的方式來安裝插件，不是特別的方便。
^_^，由于我當時使用的時候equinox還沒提供osgi中httpservice的實現，便使用了oscar中提供的httpservice的實現，基于這個httpservice的實現寫了一個web端的插件管理的工具，呵呵，將來整理后會將這個bundle公布出來，到時大家直接下載就可以用了。
在部署方面還有一個不方便的地方就是不能指定插件的啟動順序，現在equinox是通過config.ini中來實現插件啟動順序的控制的，這個在我的web端的插件管理工具中也提供直接，可直接設定插件的啟動順序。
2、Classpath的問題
這個問題是我在使用equinox時比較頭疼的一個問題，我在bundle中使用了spring IoC container，而由于spring中使用的不是當前類的加載器，導致在加載配置文件的時候會出錯，只得直接修改了spring中那些部分的代碼，將其改為使用當前類的加載器。
在集成其他一些自己含有classpath的東西的時候也很容易出現這個問題。
雖然從原理上來講這個是可以理解的，因為在插件體系結構中每個插件都擁有獨立的插件類加載器，這個確實會對集成的有些東西產生影響，抑或我們應該理解為集成的那些東西在這方面設計有缺陷？
3、有利于面向接口編程的執(zhí)行
這個應該說是屬于插件體系結構的好處，每個插件可以控制自己對外所暴露的包，這個時候就可以只暴露接口所在的包，^_^，呵呵，面向接口的編程就這么被強制的執(zhí)行了。
4、插件開發(fā)的IDE
這點是我覺得equinox的天然優(yōu)勢，擁有一個eclipse這么優(yōu)秀的插件開發(fā)的IDE，^_^
支持了插件的調試...
我認為的最重要的一點是它解決了插件依賴的問題，通常在出現project依賴的時候我們都需要引用該project或是該project生成的jar，而在插件體系結構中只需要在插件文件中定義所依賴的包即可，這個就解決了去引用project那樣方式引起整個項目工程包混亂和開發(fā)不便的現象。
5、插件的測試
這點我想也是大家很關心的，不過大家可以放心，基本沒什么不同的，unit test繼續(xù)使用Mock方式完成所測試的unit的外部依賴的部分，集成測試則需要啟動equinox容器，這點應該沒什么不能接受的。
6、Bundle和Service的定義
這個就是插件體系結構帶來的一個挑戰(zhàn)，如果準確的定義系統中的bundle和service是很關鍵的一個問題，這對于發(fā)揮插件體系結構的bundle級別、service級別的重用性至關重要，同時對于整個項目結構的清晰度也會產生很大的影響，形成bundle的清晰的service依賴結構。
7、面向服務的體系
我想這也同樣是象equinox這樣的插件框架引發(fā)使用者的思考，系統采用的應該是一種面向服務的體系，服務才是系統的核心，bundle只是一個管理器而已，這個時候怎么樣設計出動態(tài)、松散耦合的服務體系是很關鍵的。
equinox一直都在發(fā)展之中，它的maillist一直就非常的熱鬧，而且現在對于osgi中的service它基本都實現了，也已經開始提供對于servlet container集成的支持，^_^，極度支持equinox，雖然它還需要不斷的努力.....
可以看得出，經過我上面的總結，大家其實要擔心的是引用一種新的體系結構帶來的設計層面的變革，而不是開發(fā)實現層面，^_^