 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| プラグインの開発者にとって問題となったのは？
|
各モジュールのAPIへのアクセスを制限できるようにしているのは、モジュールの開発者が、今後更新するかもしれない内部のパッケージやAPIであることを、モジュールを利用している開発者に示せるようにしたかったからです。
Eclipse IDEは年に1度のメジャーリリースをするというペースを保っています。これはとても大変なことです。このペースを守るために、頻繁に変わるであろう内部のパッケージやAPIを、できるだけ簡単に理解できることが必要となります。公開されていないAPIとわかっていれば、依存するプラグインのバージョンアップ時に、発生したAPIの変更による影響をできるだけ少なくすることができます。
この対応についても第1回で簡単に触れましたが、Bundleの外部へ公開するパッケージを制御できます。OSGiフレームワーク上ではMANIFESTファイルにて公開するパッケージを「Export-Package」として指定します。他のBundleからは参照できる部分が制限されていますので、内部APIかどうかを判断できます。
Eclipseプラットフォームはプラグインシステムを採用してから、機能拡張を高速に行えるようになりました。Eclipse 3.2では700万行のソースコード、10のプラグインプロジェクトが公開されていたのが、Eclipse 3.3では1,700万行のソースコード、21のプラグインプロジェクトが公開され、倍以上に増えました。ソースコード総数は実装効率の影響かもしれませんが、プラグインプロジェクトの数がほぼ倍に増えているという点は、機能もほぼ倍に増えていることを示しているといえるでしょう。
|
| プラグインシステムをどのように作成するのか？
|
Eclipseプラットフォームのようなプラグインシステムを解説するために用意したのが、連載の第3回で公開し、第4回で簡単に解説したサンプルのアプリケーションです。Eclipseではプラグインと呼んでいますが、プラグインはすべてOSGiフレームワーク上ではBundleとして扱われます。そこで第4回はBundleの組み合わせについて解説しました。
|
| JARによるライブラリの配布は依存関係になやまされませんか？
|
今回解説のために作成したサンプルアプリケーションの開発にてちょっとした問題を抱えました。連載の第3回のサンプルアプリケーションではThink ITにて配信されているRSSの受信機能を動的に追加しました。RSSの受信機能はBundleの内部でROMEというRSSを扱うライブラリを使用しています。
このROMEというライブラリは内部でXMLを解析するためのライブラリ「JDOM」を使用しています。
開発をはじめる前にROHMを用いてRSSの受信のテストを行うため、簡単なコードを記述し、動作を確認しようとしました。しかし動作しません。この時点ではJDOMを用意していなかったのです。ROMEのWebサイトではJDOMに依存していることが明示されていますが、ROMEをダウンロードできるトップページや配布されているパッケージには、JDOMに依存していることを記述したドキュメントは含まれていませんでした。
筆者は最初ROMEがJDOMに依存していることに気づかず、原因の調査に時間を割きました。このようにライブラリ利用者はライブラリの依存関係について知る必要があります。ライブラリが利用しづらい一因には、こういったライブラリの依存関係があるのではないでしょうか。
OSGiの環境下ではBundleごとにクラスパスを設定することができます。そのため、Bundle形式でライブラリが配布されればこういったライブラリごとの依存関係をあらかじめ指定した上で配布することができます。こうなれば、Bundleの利用者はライブラリの依存関係について悩まされることが少なくなります。
Bundleごとにクラスパスを設定できると、サービスを利用する側は、実装側がどのようなライブラリを使用して実装しているのかを知る必要はありません。RSSを受信する機能以外にも、例えばメールの着信を確認するような機能を追加するBundleを作成することもできるでしょう。その場合は、JavaMailなどのライブラリを使うと良いでしょう。
Bundleに定義されているサービスについて情報が公開されていれば、そのアプリケーションの開発者以外の方でもサービスを追加することができます。第4回で解説したServiceTrackerを利用することで、BundleContextに登録されているサービスを追跡できるためです。
サンプルのアプリケーションでは受信したRSSをティッカー表示させました。例えば1日に受信したRSSをまとめて手元に記録しておくサービスを追加することもできるでしょう。
でもこうしたサービスは作成したり、修正すると瞬時に動作を確認できたほうがうれしいのではないでしょうか。
|
| アプリケーションを止めることなくモジュールを更新するには？
|
OSGiフレームワークでは動的にモジュールの追加や更新を行うための仕組みを用意しています。OSGiコンソール上でのinstallコマンドやupdateコマンドなどを使うと、モジュールのライフサイクルを制御することができます。これらのコマンドについては第3回にて解説しました。
installコマンドによってモジュールを動作しているアプリケーションへロードし、startコマンドによってモジュールの動作が開始されます。モジュールを更新した場合はupdateコマンドとrefreshコマンドを実行すると、ロードされているモジュールが再度読み込まれます。またstopコマンドやuninstallコマンドを実行するとモジュールの動作を停止したり、削除することができます。このような動的な機能の制御をOSGiフレームワークでは実現しています。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社チェンジビジョン 近藤 寛喜
モデリングツールJUDEを開発しているチェンジビジョンにて、プロジェクトの現在を見える化し、状況を共有することで現場で起きている問題を解決するためのツールTRICHORDを開発している。以前からオープンソースのプロジェクトに興味を持ち、特にEclipseプラットフォームに心酔している。最近はゲームの操作感を刷新したWiiリモコンを使って何か面白いUIが作れないか模索している。
|
|
|
|
|
|
