Eclipseの動作をカスタマイズするための
Eclipseのフィーチャーの使い方
Pat McCarthy
Senior Software Engineer.IBM
2004/2/28
|
プラグインの開発は楽しい。コードを書いて、自分の望むツールを作成できるからだ。このプラグインは、Eclipseの既存の「\plugins」ディレクトリにコピーするだけで、Eclipseランタイム環境もしくはEclipseベース製品の中で使えるようになる。コピーした後の次のEclipseの起動時に自動的にプラグインが見つかり、プラットフォームの起動処理を完了すれば、これがランタイムコンフィグレーションで利用できるようになる。
しかし、プラグインが読み込まれようが読み込まれまいが関係ないと思われるだろうか？ ユーザーはあなたのツールの動作を理解するだろうか？ ユーザーは寄与されたコードをEclipseを使って使用不可にしたり、保守あるいは管理できるようになるだろうか？ そのようなことは絶対にない。プラグイン単体は1つのプラグインでしかなく、Eclipseプラットフォームと完全に統合された寄与ツールにはならない。
 |
フィーチャー・パッケージプラグイン |
フィーチャーがなければプラグインは扱いにくい。つまり分かりやすくいうと、フィーチャーのないプラグインは管理されていないプラグインということだ。Eclipseプラットフォームの起動処理にはコンフィグレーション処理が含まれている。新しいプラグインが「\plugins」ディレクトリにコピーされるか、起動時にEclipseに認識されれば、コンフィグレーションのステップが認識し、スプラッシュイメージを2回点滅表示するだけではあるものの、認識したことをユーザーに通知してくれる。Eclipseが新しいプラグインを認識するのは、現在のワークスペースの「\.metadata\.config\platform.cfg」ファイルに格納されたコンフィグレーションのチェックサムが異なるためだ。プラットフォームがコンフィグレーションの修正をユーザーに細かく指示するフィーチャーが提供されていないため、Eclipseにはスプラッシュ画面を点滅表示することしかできない。しかし、自分のプラグインを1つ（もしくは2つ）のフィーチャーにパッケージングすることで、次のようなことが可能になる。
- Eclipseのコンフィグレーション処理で使う提供プラグインの必要条件を（「feature.xml」ファイル中に）一覧する
- アクティブなEclipseコンフィグレーションの一部として提供プラグインを管理する
- ランタイム環境の利用者に対して提供プラグインを識別するためのブランド情報と、ユーザーに自分のフィーチャーの内容を示す歓迎ページ（自分のフィーチャーと関連付けた「welcome.xml」ファイル）を提供する
- Eclipseアップデートマネージャを使って提供プラグインの保守を行う場合もある
フィーチャー・パッケージの登録はプラグインの開発が終わるまで待っていてはならない。フィーチャーの定義に反映される設計判断は、プラグインの構造に影響する可能性がある。例えば、Eclipseの大半の提供プラグインはUIとコア（UI以外）の機能を持っている。自分が開発するプラグインがこのように分割されていない場合は、即座に改訂を検討すべきかもしれない。また、フィーチャーは参照されるプラグインのビルド処理自動化にも利用できる。
|
製品を強く印象づけるプライマリ・フィーチャー （ただし管理は自分で可能） |
フィーチャーが多数あってもEclipse起動時に管理できるのは1つだけだ。このプライマリ・フィーチャーは、ランタイムプラットフォームの名前と関連グラフィックスの特定のほか、全プラグイン用のデフォルト初期設定の再定義など、製品のブランドとランタイム時の各種動作を識別する。これは自分独自のEclipseインストレーションをカスタマイズする際に利用できる強力なオプションとなり得る。
■プラグインを構築するフィーチャー（許可が前提）
Plug-in Development Environment（PDE）は、完全なランタイム環境向けにフィーチャーとプラグインコンテンツを用意するタスクの大半を自動化してくれる。Eclipse.orgにある「PDE Does Plug-ins」を参照されたい。基本手順は『The Java Developer's Guide to Eclipse』でも、既存のプラグインのビルドとブランド登録の際の演習課題として文書化されている。フィーチャーがあり、PDEがプラグインとフィーチャーのビルドをどのように支援してくれるのかを理解していれば、フィーチャーをビルドすると同時に、これに関連する全プラグインをビルドさせることが可能であることを覚えておいていただきたい。コントロール戦略のビルド（「bin.excludes」と「bin.includes」）は「PDEを使ったフィーチャーのビルド戦略」で解説する。これらの戦略は、Eclipse.orgの記事や『The Java Developer's Guide to Eclipse』で学ぶ内容を補完してくれる。
|
プラットフォームのコンフィグレーション管理 |
フィーチャーの必要性を理解するためには、アクティブなコンフィグレーションで利用可能なコンテンツを、これらがどのように管理するのか理解することが有用だ。
■起動処理
全くの初期状態にあるEclipse Platformファイルの中の「eclipse.exe」を起動すると次のような処理が行われる。
- Javaランタイム環境（JRE）が見つかる。デフォルトでは、Eclipseはまず「eclipse\jre」サブディレクトリを探し、そこにない場合はオペレーティングシステムが認識している場所を探す。
|
- コンフィグレーションは新しいワークスペースの一部として作成される。一般的に、新しいワークスペースにはコンフィグレーションが全くなく、スプラッシュイメージの前に「Completing
the install」イメージが表示されるのはそのためだ。
- Eclipseが認識しているフィーチャーとプラグインが処理され、将来的な変更を検知するためのチェックサムが生成される。これにはリンクファイルで識別される「eclipse\...」ディレクトリ構造のほかに、現在の「eclipse\features」および「eclipse\plugins」の両ディレクトリにあるフィーチャーやプラグインが含まれている。
|
Eclipseが起動すると、「\.metadata\.config\platform.cfg」ファイルがアクティブなコンフィグレーション定義を含むようになる。
■リンクファイルによるEclipseインストレーションの拡張
しばらくEclipseを使っていたり、コンフィグレーションにたとえ1つでも新しいプラグインを追加した場合は、Eclipseが「eclipse\features」と「eclipse\plugins」の両ディレクトリでフィーチャーやプラグインを探すのはご存じだと思うが、Eclipseがファイルシステム中のほかの場所も探すことはご存じだろうか？ 「eclipse\links」ディレクトリに適切にフォーマットされたリンクファイルが存在する場合は、これらが処理され、関連するフィーチャーやプラグイン（参照機能のないプラグインも含む）がランタイムコンフィグレーションでも利用可能になる。
リンクファイルは「id.link」という名前のすべてのファイルを指し、idは慣例上、参照されるルート・フィーチャーのIDを利用する。それでも、リンクファイルターゲットには複数のフィーチャーを配置することができるほか、「foo.link」といった名前でも問題なく動作する。次のようなリンクファイルが考えられる。
path=E:/Eclipse-2.1.1/installedFeatures/Examples |
Eclipseは識別されたディレクトリから、正しいフィーチャーや提供したプラグインのある「eclipse\features」および「eclipse\plugins」ディレクトリを探す。つまり、ターゲットとなるディレクトリには「\eclipse」ディレクトリが含まれていなければならないことになる。これが見つかれば、追加機能とプラグインがランタイムコンフィグレーションでも使えるようになったり、リンクファイルがワークスペースの作成後に追加された場合は新たなコンフィグレーションの変更として処理することができる。
リンクファイルを使って自分独自のEclipseインストレーションをカスタマイズするための戦略については、後編の「リンクファイルを使ったEclipseインストールの管理」で解説する。
■コンフィグレーションのアップデート（フィーチャーの追加）
参照されたプラグインを持つ新しいフィーチャーが既存の「\features」および「\plugins」の両ディレクトリに追加されたり、リンクファイルでEclipseに認識されると、チェックサムの変化によってコンフィグレーション処理が起動される。この処理では、単純なスプラッシュ画面の表示以外に、この新機能がコンフィグレーションの変更として処理され、「Configuration Changes」ダイアログが表示される。
例えば図1のダイアログは、標準のEclipseパッケージでワークスペースを開き、それからEclipse Examplesを見つけてこれをEclipseと同じディレクトリツリーに解凍したか、サンプルを解凍した先を指すリンクファイルを追加した場合に表示される。
 |
| 図1 「Configuration Changes」ダイアログ |
従って、このようなダイアログが表示されるのは、新しい、もしくはアップデートされたフィーチャーを利用できるよう、自分、実行したインストールプログラム、あるいは他人がEclipseのインストレーションを修正したためだ。エントリを選択できる場合は、現在のコンフィグレーションに変更を加えることができる。エントリが無効になっている場合は、コンフィグレーションの問題で新しいフィーチャーが登録できなくなっている。「Error Details」ボタンはコンフィグレーションの問題に関する情報を提供してくれる。
■コンフィグレーションの管理に関するメモ
- 変更処理がたまっているからといって、これらをいま実行しなくてはならないわけではない。変更処理はしばらくそのままにしておくことができる。エントリの選択を解除して「Finish」をクリックするだけだ。これらを後で登録するときは、メニューオプションの「Help」>「Software
Updates」>「Pending Changes…」でこのダイアログを再度開けばよい。
- 処理を行った変更については後から無効にすることもできる。「Install/Update」パースペクティブを開き、「Install Configuration」ビューでフィーチャーを選び、「Preview」ビューの「Disable」を選ぶ。同じ処理を行えば、無効になったフィーチャーを後で再び有効にすることができる。無効になったフィーチャーを「Install Configuration」ビューで確認するには、「Show Disabled Features」のトグルボタンを選択する。
| 1/2 |  |
|
INDEX |
||
| Eclipseのカスタマイズの勧め（前編） | ||
 |
Page1 フィーチャー・パッケージプラグイン 製品を強く印象づけるプライマリ・フィーチャー プラットフォームのコンフィグレーション管理 |
|
| Page2 フィーチャーを強く印象づけることでランタイム時に自分が提供したプラグインを識別する PDEを使ったフィーチャー・ビルド戦略 フィーチャーの構造化 |
||
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
