放棄使用OSGi方式
OSGi是什么
OSGi是一種服務運行平臺。通過實現能夠提供服務的符合OSGi規范的組件，用戶可以將其組件發布到OSGi運行平臺，供用戶和其他組件使用。
OSGi 組件提供的服務具有兩個層面的含義：系統層面，即一個組件為其他組件提供服務，這些服務體現為Java接口的實現；業務層面，即一個組件為外部系統或用戶提供某種業務服務實現。
51CTO編輯推薦：OSGi入門與實踐全攻略
記錄下傳統和OSGi方式的開發方式的特點：
傳統方式的開發 ：
開發時，要引入整個依賴包。整個系統為一個工程，里面包含了各個功能模塊。（假如不使用像maven之類的工具管理模塊依賴的話，在eclipse中開發確實是個比較頭疼的問題）
OSGi方式的開發 :
模塊的依賴，只需要引入使用到的接口。不需要引入整個bundle。（基于eclipse 的插件開發就是這種類型）只需要將bundle部署到服務器上，即可為系統增加相應的模塊支持熱拔插（其實這個功能，雖然很好，但是對于企業級開發，感覺意義不大。對于嵌入式那就另當別論了）
OSGi在很大的部分上也是對模塊的管理，開發都是基于服務的，我覺得這樣很好，不過目前來說，我覺得在企業級應用里面使用還是為時過早。目前使用的maven 加 soa的方式已經可應對大多問題了。
所以我最終決定目前放棄使用OSGi方式：
考察了OSGi很久，最終決定放棄使用該技術作為zog平臺的模塊管理框架。還是使用目前使用得很多的maven+soa進行開發。主要有以下考慮：
1.OSGi 目前不成熟。特別在B/S方面，因為大多數應用服務器都不支持OSGi，這樣讓部署很困難，而且目前已有的解決方案也不好。OSGi是底層的，我認為他應該在服務器級提供實現，或者jvm級實現。給應用層增加一層OSGi是不明智的。
2.maven管理模塊的依賴目前還是很成熟了。maven的模塊管理是傳統意義的管理，即把包作為jar包導入引用工程。由于maven強大的包管理功能，使得包依賴問題得到了解決。光從開發這點上OSGi沒有明顯的優勢，因為在基于OSGi開發中，要引用其他包，必須在eclipse中把這些作為一個個工程打開，其他工程才能引用它們（想想假如你有100個bundle的情況，就可想而知！）。
3.假如光把OSGi作為zog平臺級開發使用，而在開發具體項目時采用普通開發模式，咋樣呢？依據我目前掌握的OSGi知識來看，我不贊同這樣。首先問題的原因也如同剛剛2所提到的，同時也考慮到zog平臺打包的問題。你想想，bundle是按照功能來創建的，為了管理這些小東西，也會打開很多的模塊工程。很麻煩。
4.以后等OSGi成熟了，轉換過程也很簡單。不過前提是要對架構設計好才行。
【編輯推薦】
