前回の bundle.update 以来、OSGiとモジュールJavaの世界に、いくつかのおもしろい事が起きた。JSR 294が凍結とマークされ、Enterprise Expert Groupがドラフト４をリリース、WebSphereで、OSGiアプリケーションが直接動作するようになり、次回のOSGiコンファレンスの早期ディスカウントと講演者の募集がまもなく終わる。
JSR 294の凍結
モジュール性 (JSR 294、Java言語における改善されたモジュール性のサポートと JSR 277、Javaモジュールシステム) に関する２つのSun主導のJSRが、今や凍結状態になった。これで、 JCP 承認の モジュラティ システムは、 JSR 291だけで、これは、ちょっと古い OSGi 4.1をベースにしているが、広く多くの様々なシステムで活発に使われている。この中には、Sunが最近リリースした GlassFish v3 アプリケーション サーバも入っている。
JSR 294が最近凍結状態にされた、理由ははっきりしない （JSR 277は、１年間凍結されている）。 グループへの最後のメッセージ から推察されるのは:
- JSRの実装に加えて、JDK7は、実装特有のフィーチャ、例えばa) クラスパス（いかなるJSRの一部ではない） b) Jigsawモジュール・システムを持つ。
- JDKのモジュール化には、Jigsawモジュール・システムが使われている。モジュールの可視性は、プロトタイプ的なmodule-info.javaファイルによりコントロールされる；これは変わるかもしれない。モジュール-非公開のアクセスビリティは、実際このモジュール化で使用されておらず、部分的にブースト・ストラップを助けている。
- Jigsawのあらゆる面での更なる議論は、 Jigsaw-dev listにある。
simple module system （シンプル・モジュール・システム）が提案されてから進歩がなかった。 バージョンのセマンティクスがJSR294によって管理されると、ほのめかされたが、明らかにそうは、ならなかった。開発は、JSR 294の専門家メーリング・グループ外である jigsaw-devのメーリングリスト上で行われたからである。それ自体が、称賛に値する目標である、JDKをモジュール化するために、Jigsawは、実装特有のフィーチャであり、一度書けば、どこでも走るという、結果にはならない、ことが上に述べたことから推察される。このことは、将来、いかなる場合でも影響してこないだろう。JDK7は、早くても２０１１年までリリースされそうにない。アップ・サーバは、すでにOSGiに賭けている。
アップデート: この記事が載ってから、Alex Buckley氏が 確認した のは、プロジェクトを終わらせるためにではなく、最初の提案が出ててからある期間過ぎると、自動的に、凍結に成る、と言うことである。
WebSphere, GlassFish, DM Server OSGiベースのサーバ
Kirk Knoernschild氏は、 OSGi化しているエンタプライズ ソフトについて述べている; 最近の公表によると、 WebSphere V7 α版 では、OSGiのバンドルがWebSphere中にデプロイできるようになった（WebSphereは、２００６年以来OSGiのカーネル上で走っているが）。
今週リリースの GlassFish v3 もまた、SunのエンタプライズJavaサーバにOSGiのランタイムを持ち込んだ。GlassFishは、OSGiのバンドルを直接、そのままで走らせることは、できないが、Equinox やFelixにホストすることができるので、GlassFishサーバを走らせて、同時に他のバンドルを走らせることができる。
SpringSourceの dmサーバ 2.0.0.M6 は、すでに バンドル・レポジトリとともにOSGi のwebバンドルを走らせることができ、エンタプライズ用のランタイムに向かう道を示している。
Maven 3とTychoのビルド、リポジトリとMarketplace
OSGiベースのアプリケーションのために、Tycho のビルドとともにMaven 3 のリリースが近づいている。 Eclipseで EGit と Tigerstripe をビルドするのに使われている。
リポジトリ対P2リポジトリのクエリ能力について議論がこれまであった。しかし、実際は、 Mavenリポジトリもクエリすることができる。おそらく、Mavenリポジトリは、Mavenのビルド・プロセス全体で最も成功した点の１つであり、成果物を依存性の要求に基づいて、自動的にダウンロードできる。Pack200圧縮と非JARのコンポーネントを更新できる点では、 P2 は、もっと進んでいる。Mavenの üuber リポジトリは、EclipseのP2リポジトリを幅において、はるかに優っている。さらに、P2リポジトリは、しばしばいくつも、別々のリポジトリに断片化するが、一方、Mavenは、すべてのプロジェクトが共有する単一のグローバルなリポジトリである。
最近、 Eclipse foundation が成功している Eclipse Plug-In Centralサイトから成長したEclipse Marketplaceを公表した。 EPICは、元々 Findbugs や Checkstyleのような基幹のEclipse.orgサイトにホストされない人気のプラグインをダウンロードする中央サイトを提供する手段として作られた。
The Eclipse foundation が２００６年に EPICの権利を買った が、それからEclipse marketplaceの最近の展開までほとんど何も変わらないままだった。その間、集中したダウンロード用の構造がないので、Update Site からP2に切り替える苦痛のために、プラグインを見つけ、ダウンロードする目的の中央サイトに関して、提案されたフィーチャや利益が損なわれている。
プラグインに加えて、新Marketplaceは、(フリーと商用の)RCPアプリケーションやトレーニングやコンサルの提供者のためのマーケットも扱う。
最後に IntelliJ 9 がリリースされた。コミュニティ版も商用版もOSGiアプリケーションのビルドをサポートしている。最高のJavaIDEでOSGiアプリケーションをネイティブにビルドできるし、OSGiアプリケーションのヘッドレス・ビルドもサポートしているので、モジュール化されたJavaアプリケーションの開発は、これまで以上に容易になった。
OSGi 4.2 EEGのドラフトが公開
OSGiの Enterprise Expert Group が 早期ドラフト４を公開した。EEGの目的は、JEEスタイルのアプリケーションがOSGiランタイムで、バンドルとしてネイティブにホストされるように、仕様を定義することである。
- Web appsは、今やバンドルとしてインストールできる。これにより、OSGiランタイムがWARをホストできる（Jettyのようなサーバと同じ方法で）し、WARもまた、実行時にバージョン付きの依存性を持つことができる。以前は、 Pax Webによりこのようなことができたが、標準ができたために、どんなOSGiのランタイムも使えるようになる。
- JMX は、OSGiフレームワークにおいてバンドルやPackage AdminやCofniguration Adminなどを管理する。
- トランザクション は、JTAバインディングの一部として提供され、トランザクションは、OSGiサービスから獲得できる。
- JNDI アクセスは、OSGiサービスからとOSGiサービス間で、できる。
- JDBC factoryは、OSGiコンパチである（
Class.forName()違って）。
これらのサービスにより、エンタプライズ アプリケーションは、全JEEスタックを必要とせず、OSGiの環境内で動作できる。 JEE6がリリースされたが、これは、承認された最後のJSRの一つになりそうである。と言うのは、 Mark Reinhold 氏がクロージャのQ&Aでコメントしている:
Q なぜ今、クロージャのJSRがスタートしないのですか？専門家グループに新しい提案をまとめる仕事をさせないのですか？
A 同じ理由で、Project CoinのJSRもまだありません。すなわちJCP 執行会議で 現在の論争が終わらないと新しいJava SE JSRは、承認されません。
次回のOSGiコンファレンス
ロンドンで２０１０年２月２３日に OSGi DevCon London が JAX Londonといっしょに開催される。 コンファレンスのプログラムは、決まり、Kirk Knoernschild氏が基調講演を行う。１２月１７日木曜日まで早期登録ができる。
サンタクララで、２０１０年３月２２～２５日に OSGi DevCon が EclipseCon 2010 と一緒に開催される。 Robert "Uncle Bob" Martin 氏が基調講演を行う。早期登録は、１２月末で終了。講演者をまだ募集中だ。もしOSGiについて語りたければ、提案書を提出するとよい。