Equinox，我不想多做介紹，相信很多人都有所了解了，不了解的可具體去 www.eclipse.org/equinox 看看。
最近基于equinox做了一個系統，還是碰到了一些問題，當然也得到了在插件體系架構下的不少優點，在這里也做個總結。
總體而言，基于equinox做開發對于大多數java開發人員來說應該不會有太多改變的感覺，最多改變的感覺應該是帶給設計師，設計師需要有發揮插件體系架構優點以及減少其帶來的缺點的能力，^_^
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、有利于面向接口編程的執行
????? 這個應該說是屬于插件體系結構的好處，每個插件可以控制自己對外所暴露的包，這個時候就可以只暴露接口所在的包，^_^，呵呵，面向接口的編程就這么被強制的執行了。
4、插件開發的IDE
????? 這點是我覺得equinox的天然優勢，擁有一個eclipse這么優秀的插件開發的IDE，^_^
????? 支持了插件的調試...
????? 我認為的最重要的一點是它解決了插件依賴的問題，通常在出現project依賴的時候我們都需要引用該project或是該project生成的jar，而在插件體系結構中只需要在插件文件中定義所依賴的包即可，這個就解決了去引用project那樣方式引起整個項目工程包混亂和開發不便的現象。
5、插件的測試
??????這點我想也是大家很關心的，不過大家可以放心，基本沒什么不同的，unit test繼續使用Mock方式完成所測試的unit的外部依賴的部分，集成測試則需要啟動equinox容器，這點應該沒什么不能接受的。
6、Bundle和Service的定義
????? 這個就是插件體系結構帶來的一個挑戰，如果準確的定義系統中的bundle和service是很關鍵的一個問題，這對于發揮插件體系結構的bundle級別、service級別的重用性至關重要，同時對于整個項目結構的清晰度也會產生很大的影響，形成bundle的清晰的service依賴結構。
7、面向服務的體系
????? 我想這也同樣是象equinox這樣的插件框架引發使用者的思考，系統采用的應該是一種面向服務的體系，服務才是系統的核心，bundle只是一個管理器而已，這個時候怎么樣設計出動態、松散耦合的服務體系是很關鍵的。

equinox一直都在發展之中，它的maillist一直就非常的熱鬧，而且現在對于osgi中的service它基本都實現了，也已經開始提供對于servlet container集成的支持，^_^，極度支持equinox，雖然它還需要不斷的努力.....
可以看得出，經過我上面的總結，大家其實要擔心的是引用一種新的體系結構帶來的設計層面的變革，而不是開發實現層面，^_^?

基于Equinox開發系統的總結