NagarroのBill Kayser氏は最近アプリケーションをカスタムインフラストラクチャとビルドプロセスからOSGiに移行する自身の体験をブログに記載した(source)。エンデバー上の最初の二つのブログエントリーにおいて、彼はJVM内のSOA(source)という側面から見たOSGiを興味深く紹介している。二つ目のエントリにおいて、彼はコンベンションプロセスそのものを取り上げている。OSGiへの移行の一番の理由はビジネス条件に基づいたものである。しかし、Kayser氏は予期していな かったもう一つの利点に驚きと喜びを見せている。
新たに成された向上には下記の点がふくまれている。
・・・チームメンバー達は以前のリリースビルドに戻らなければいけない状況を考えた後に、OSGiを知ったことについて未だに私にお礼を言いに来ます・・・
- 25000ラインのフルビルド用に必要なantコードから約200ラインの用語設定に加えてプラス200ラインのカスタムコールバック
- エクストラのクラスを確実にするため、故意に間違ったjarファイルを使われないようにしたり、もしくは不必要な重複した70のクラスファイルカタログを取り除いた
- 使用されていない依存性を除去することによってアプリケーションディストリビュージョンのサイズを削減する
- 紛失したクラスとライブラリへのダングリングリファレンスに基づいた未知のバグを事前に表面化する
- カスタムクラスローダを使用した分離クラススペースを伴う拡張機能を管理するため投入された大規模なコードの塊を除去
- それぞれのアプリケーション-IDEクラスパス、IDEローンチャー、ランタイムスクリプトクラスパス、ビルドスクリプトクラスパス用の4つの異なるランタイム設定から、それぞれのアプリケーションによって構成されたOSGiバンドルのシングルフィーチャーディスクリプタリスティングの管理まで
関連トピックにおいてRed MonkのMichael Cote氏は最近"OSGi in Java- Eclipse Equinox Screencast and Video Series 提供：Eclipse Foundation"を掲載している(source)。Cote氏はそこでEnterprise OSGi入門、Eclipse RAPを伴うAjax、サーバサイドのOSGi等のトピックに立ち向かっている。
原文はこちらです：http://www.infoq.com/news/2008/01/osgi-success