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