SpringSourceはGroovyで動作するGradleの熱心な支持者であり、1年半前からビルドシステムをMavenからGradleへ移行している。3.2の開発完了が近づく中、Maven Centralへ発行されるビルド用のOSGiメタデータの生成が行われなくなるようだ。
SpringSourceはかつてはOSGiの熱心な支持者(Rod Johnson氏への2008年のインタビューを参照されたい)だったが、徐々にOSGiとモジュール化技術から離れていった。Spring Roo(2010年にOSGi上で動作している)やSpring Dynamic Modules(2008年にリリースされた)のような製品はOSGiへ投資していたが、Bundle-Nameと正確なバージョンによって依存関係を厳しく制約するというような設計方針(Import-Packageとバージョンの幅によって柔軟に制約する方法ではなく)によって導入が進まなかった。これらの設計上の失敗はまだSpringSource EBRで生きている。
また、Spring Dynamic Modulesランタイム上でルチテナント機能を提供することに注力したのも多くの問題を生み、商用利用を妨げた。2009年、Spring DMはEclipse Foundationへ移管され始め、最終的にはEclipse Virgoになった。
そのころから、Rod Johnson氏は考えを変え、昨年の中ごろにはOSGiは簡単ではないと発言している。OSGiメタデータがあるSpringの最後のバージョンは昨年末にリリースされたバージョンであり、Gradleへの移行によりOSGiメタデータは含まれなくなる。3.1のサービスはどれもOSGiメタデータを持っており、Mavenでビルドされている。しかし、GradleがMaven Felix BNDプラグインと同様に動作するOSGiプラグインを提供するにもかかわらず、3.2はMavenではビルドされない予定だ。
Rod Johnson氏は今年、SpringSourceを退職したが、一連の意思決定やビルドシステムの移行は適切に進んでいる。OSGiの放棄も新しいSpringSourceの経営陣で行われているのだろう。いずれにしろ、OSGiに依存しているSpringSource EBRとEclipse Virgoにとっては不安な状況だ。将来は、OSGiに準拠したSpringのモジュールはコミュニティがサポートするEBRからしか手に入らなくなるかもしれない。ファイアウォールの内側からは手に入らないかもしれないし、Maven Centralからしかモジュールを入手できない場合も入手できないだろう。
Springのすべての製品からOSGiメタデータがなくなることにあなたは関心があるだろうか。Gradleが普及することでMaven CentralのOSGi関連のコンテンツは少なくなるだろうか。