Eclipseのカスタマイズの勧め(前編)
Eclipseの動作をカスタマイズするための
Eclipseのフィーチャーの使い方


Pat McCarthy
Senior Software Engineer.IBM
2004/2/28



本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。
 ほかのユーザーと共有できるプラグインを開発したい場合は、フィーチャーを効果的に使う方法の学習が絶対不可欠だ。本稿は、フィーチャーを構造化する方法、Plug-in Development Environmentの機能やプラグインビルド機能を最適な形で利用する方法、そしてEclipseの動作をカスタマイズするための上級テクニックを提案する。あらゆるワークスペース向けの初期値をカスタマイズできるようEclipseの設定方法だけを習得したい場合や、Eclipseに登録した提供プラグインを管理するためのリンクファイルの使い方だけを習得したい場合も、本稿が有益な情報を提供できるだろう。

 プラグインの開発は楽しい。コードを書いて、自分の望むツールを作成できるからだ。このプラグインは、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」サブディレクトリを探し、そこにない場合はオペレーティングシステムが認識している場所を探す。
メモ
代替JREの特定にはdirのロケーションアーギュメントである-vmが利用可能。
  • コンフィグレーションは新しいワークスペースの一部として作成される。一般的に、新しいワークスペースにはコンフィグレーションが全くなく、スプラッシュイメージの前に「Completing the install」イメージが表示されるのはそのためだ。

  • Eclipseが認識しているフィーチャーとプラグインが処理され、将来的な変更を検知するためのチェックサムが生成される。これにはリンクファイルで識別される「eclipse\...」ディレクトリ構造のほかに、現在の「eclipse\features」および「eclipse\plugins」の両ディレクトリにあるフィーチャーやプラグインが含まれている。
Completing the install
ワークスペースがすでに存在する場合は、コンフィグレーションを「\.metadata\.config\platform.cfg」ファイルに含める。Eclipseのインストールを正式にインストールされた製品のように管理している場合は、「eclipse-initialize」コマンドを起動し、「eclipse\.config」ディレクトリでデフォルトの初期コンフィグレーションを行う。これにより、新しいワークスペースを使っているときに「Completing the install」のイメージなしでEclipseが起動するようになる。

 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を使ったフィーチャー・ビルド戦略
フィーチャーの構造化







Java Agile フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Java Agile 記事ランキング

本日 月間