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


フィーチャーを強く印象づけることでランタイム時に
自分が提供したプラグインを識別する

　Eclipseでは、アクティブな製品や、ランタイムコンフィグレーションに含まれる各機能には任意でブランドを登録することができる。フィーチャーにブランドを登録しなければならないわけではないし、どのフィーチャーにもブランドを登録しないことも可能だが、少なくとも1つにはブランドを登録しておくべきだ。

■ブランド登録の定義（プラグインの仕事）

　ブランドを登録するときの秘けつは、定義の置き場所がどこか把握しておくことだ。フィーチャーにブランドを登録するのは自分だが、ブランドを登録するコンテンツはプラグインによって提供される。これは、フィーチャーと同じidを持つプラグイン（デフォルト処理）、もしくはフィーチャーの定義で識別されるプラグイン（Eclipse 2.1.1の新オプション）のいずれかだ。Eclipse 2.1のフィーチャーの定義では「feature.xml」ファイル中の「plugins=...」属性を使って代替プラグインを定義することができる。

　プラグインには、ブランドを登録するコンテンツの定義と提供に使われる両方のファイルが含まれている。

■コンテンツにブランドを登録する方法の概要

　「about.ini」コントロールファイルは、製品およびフィーチャーレベルでのブランドを登録するコンテンツを定義する。製品のブランド登録には以下の2つが必要となる。

  • そのフィーチャーを潜在的なプライマリ・フィーチャーとして定義する必要がある。つまり、「feature.xml」定義に「primary="true"」という記述が必要になる


  • そのフィーチャーをアクティブなプライマリ・フィーチャーとして識別する必要がある。一般的に、これは「\eclipse」ディレクトリにあるinstall.iniファイルの中のエントリを使い、製品の中で行われる。プライマリ・フィーチャーは「-feature featureId」起動パラメータを使ってランタイムでも定義することができる

　フィーチャーにブランドを登録する最も簡単な方法は、「about.ini」コントロールファイルでどのエレメントが定義されていて、これらがブランド登録された製品やフィーチャーのどこにいくのか考えることだ（図2）。

図2　Eclipseパースペクティブを使ったコンテンツへのブランド登録

　以下のエントリは製品へのブランド登録にのみ適用される。

  • windowImage
  • appName
  • aboutImage

　残りのエントリは製品および機能の両方へのブランド登録で利用される。

　「％」に続く値は「about.properties」ファイルで解決される。「aboutText」キーによって定義されたテキストは機能がアクティブなプライマリ・フィーチャーになったときに「About “製品名”」ダイアログに表示される。このテキストは、「Feature Details」ボタンで開く「About Features」ダイアログで選択されていればどの機能でも表示される。

　「welcomePage」エントリで識別される「welcomePage」は、機能が最初にランタイムコンフィグレーションに登録されたときに開き、Eclipseの「Help」>「Welcome...」メニューオプションで開く「Welcome」選択ダイアログを使えばいつでも見ることができる。

　機能するブランド付きフィーチャーを構築するには、Eclipse本体のエントリをクローン化する方法が最も早い。「org.eclipse.platform」というidを持つフィーチャーやプラグインは、フィーチャーとプラグインの両方にブランドを登録することができる。詳しい手順については『The Java Developer's Guide to Eclipse』の第34章にある演習７に解説が用意されている。

PDEを使ったフィーチャー・ビルド戦略

　ビルドプロセスは、『The Java Developer's Guide to Eclipse』の機能の開発に関する各章およびEclipse.orgの「PDE Does Plug-ins」という記事に書かれているが、ほかにも参考資料はいくつかある。機能と参照されるプラグインをPDEを使って構築する方法を理解すれば、このプロセスは自動化することができる。

■PDEによってインプリメントされるAntターゲット

　まず、PDEによって提供されるファンクションの概要から説明しよう。PDEは「plugin.xml」もしくは「feature.xml」ファイル用に「build.xml」ファイルを生成する。「build.xml」はAntスクリプトで、ランタイムプラットフォーム向けにプラグインやフィーチャーを用意するために必要なさまざまなタイプのタスクを実行することができる。PDEのビルドプロセスでは、機能あるいはプラグイン用に以下のビルドターゲットのいずれか1つ以上を実行できるようになる。

対象となるフィーチャー・ビルドターゲット

  • 参照されるプラグイン1つ1つに対し、「build.jars」が「build.xml」ファイル内の「build.jars」タスクを呼び出す

  • 参照されるプラグイン1つ1つに対し、「build.update.jar」が「build.xml」ファイル内の「build.update.jar」タスクを呼び出す。また、このフィーチャーの「Update JAR」も作成する。これはAntスクリプトのデフォルトターゲット

  • 参照されるプラグイン1つ1つに対し、「build.sources」が「build.xml」ファイル内の「build.sources」タスクを呼び出す

  • 「zip.distribution」が、フィーチャーと参照されるプラグインで必要なすべてのファイルのzipファイルを作成する

  • 「refresh」が、フィーチャー・プロジェクトと、参照されるプラグインのすべてのプロジェクトのリフレッシュをEclipseに指示する

対象となるプラグインビルドターゲット

  • プラグイン用に定義されたランタイムJARごとに「build.jars」が「build.xml」ファイル内の多数のターゲットを呼び出す。呼び出されるターゲットの名前はランタイムJARのファイル名と一致する。これらのターゲットはJavaコードをコンパイルし、ソースフォルダに保管されたあらゆるリソースを含むJARファイルを生成

  • 「build.update.jar」がランタイムプラグインディレクトリで必要なすべてのファイルを「plugin.id_version.jar」という名前のファイルにzip圧縮する（「plugin.id」と「version」は「plugin.xml」ファイルを参照する）。これがAntスクリプトのデフォルトのターゲット

  • 「build.sources」が、特定のランタイムJARファイル向けに定義されたソースフォルダをベースにしたJavaソースのzipファイルを生成

  • 「zip.plugin」がプラグインのすべてのエレメントを含んだzipファイルを生成

  • 「refresh」がプラグインプロジェクトのリフレッシュをEclipseに指示

COLUMN
フィーチャーおよびプラグインのAnt処理では、JARアップデートもしくはzipの処理中にパッケージングされたファイルがランタイム環境で必要になる。これらは、フィーチャーやプラグイン用の「build.properties」ファイル中の「bin.includes」あるいは「bin.excludes」エントリと、各プラグインのランタイムJARファイルの中に「plugin.xml」の定義どおりに記述されている。

　プラグインを構築するにはclean、build.sources、build.jars、zip.plugin、refreshを使い、フィーチャーを構築するにはclean、build.sources、build.jars、zip.distribution、refreshを使う。すべてのパーツを強制的に作り直すよう、まずcleanから始めた方がよいだろうし、それが必須の場合も多い。Antプロセスは入力の変更に応じて必要なステップの多くを再実行するが、変更によっては必要なすべてのプロセスを起動しないものもある。テストでは、Javaのソースファイルを1つ変更すると、対応するソースのzipがアップデートされるが、クラスはコンパイルされず、ランタイムJARがアップデートされないことが分かっている。これを考えると、現在のソースのランタイムバージョンを使っていることが分かるよう、ビルドの出力を最初にクリアした方が安全だと思われる。

■解説のシナリオ

　ここでは解説が目的なので、ランタイムコンフィグレーションに不可欠な1つのフィーチャーとプラグインに絞ってコンテンツの説明をしたい。

提供プラグインの構造例
提供プラグインのタイプ ファイル
機能 feature.xml
feature_image.jpg
/license/license.html
/license/license.pdf
/plan/project-plan.doc
プラグイン 「plugin.xml」
/images/action.gif
/images/editor.gif
/src/co/pkg/id/action.java
/src/co/pkg/id/editor.java
/design-docs/plug-in.doc
/design-docs/editor.doc

　ファイル名から分かるように、ほとんどがランタイム環境に属す一方で、中には他人の目に触れる場所に置くべきでないものもある（設計書など）。

■インクルード戦略「必要なパーツの特定」

　少なくとも最初の段階では、ビルドプロセスの中でランタイムコンフィグレーションの機能やプラグインの一部としてパッケージングしたいものすべてをリストアップするのが最も簡単な方法だ。それぞれの「build.properties」ファイルを以下に示す。

build.propertiesの内容
コンポーネント 「build.properties」ファイルの内容
フィーチャー bin.includes = feature.xml,\ license/
プラグイン source.runtime.jar = src/ bin.includes = plugin.xml,\ images/

■エクスクルード戦略「不要あるいはプライベートなパーツの特定」

　もう1つが、ビルドプロセスの中でフィーチャーやプラグインの一部として望まないパッケージをリストアップする方法だ。これには共有されたくないものだけでなく、ビルドプロセスによって作成されたファイルやディレクトリ（一部は一時的なもの）も含める。このアプローチで使う「build.properties」ファイルを以下に示す。

build.propertiesの内容
コンポーネント 「build.properties」ファイルの内容
フィーチャー bin.excludes = temp.folder/,\
com.ibm.master.lab.core_1.0.0.bin.dist.zip,\
.classpath,\
.project,\
build.xml,\
build.properties
プラグイン bin.excludes = temp.folder/,\
bin/,\
.classpath,\
.project,\
build.xml,\
build.properties,\
makesrczip.xml,\
src/

　com.your.feature.idもしくはcom.your.plugin.idのフィーチャーやプラグインのid値が与えられている場合は、エクスクルード戦略で以下のようなエントリを含めなくてはならない場合もある。

com.your.feature.id_1.0.0.bin.dist.zip,€
com.your.feature.id_1.0.0.jar,€
com.your.plugin.id_1.0.0.jar,€

　zipエントリは、アップデートJARまたは配布用zip自身に配布用のzipが含まれるのを防ぐ。JARエントリはフィーチャーやプラグインのアップデートJARが配布用zipやアップデートJAR自身に含まれるのを防ぐ。

　これが必要になるのは、自分の配布用zipやアップデートJARが本来のものよりも大きい（ビルドプロセスを実行するたびにサイズが増え続けている）と感じたときだ。これらのエントリは適切なフィーチャーやプラグインの「build.properties」ファイルに入る。

■ファイルや構造の変化に対する対応

　ここまでオプションを解説してきたが、フィーチャーやプラグインに新しいファイルやフォルダが追加されたときに必要な対応も考えなくてはならない。変換が行われる可能性に対して対応するフィーチャーやプラグインを用意したとしても、これはそれぞれについて「feature.properties」と「plugin.properties」ファイルが必要なことを意味する。インクルード戦略の場合は適切な「.properties」ファイルへの参照を追加しなくてはならないが、エクスクルード戦略では変更は一切不要だ。

　どのアプローチも、ディレクトリにファイルを追加すれば変更が不要だという点では一貫している。インクルード戦略では新しいファイルが呼ばれるが、エクスクルード戦略ではそれが呼ばれない。さまざまなタイプのファイルごとに特定のディレクトリを使うべき理由はまさにここなのだ。例えば、自分のプラグインが使うすべての画像用に「images」ディレクトリを含めて、開発中にプラグインと一緒に保存しておきたい設計関連の記述や書類用の「design」ディレクトリはエクスクルードする。

　「build.properties」アップデートの作成を忘れた場合に起こり得る最悪のシナリオは、ランタイムエラーか不適切なコンテンツの配布だ。インクルード戦略を採用して新しいファイルやディレクトリを追加すると、パッケージング後はこれが利用できなくなり、これによって自分のプラグインがエラーを起こしたり、Eclipseのデフォルトイメージ（赤いボックス）が表示されることになる。一方、エクスクルード戦略を採用して新しいファイルやディレクトリを追加すると、パッケージング中にファイルやディレクトリの内容が含まれるようになる。自分のスタイルに適していて、アップデートを作成し忘れてもリスクを最小限に抑えられるアプローチを選びたい。選択をする際は、フィーチャーやプラグインが動作しないことや、ランタイムディレクトリ中のファイルが他人に見えてしまうことなど、自分にとって最も困ることが何かを基本に考えたい。

フィーチャーの構造化

　ツールを開発する際に必要なプラグインの数は考えるだろうか？ これに対する手っ取り早い回答は、自分のモデルもしくはUIのコア以外に1つ、自分のUIのコンテンツに1つ、そして提供するヘルプ用のコンテンツに1つ以上の3つだ。よく見れば、この基本的なパターンがEclipse自体でも見られることに気付くだろう（jdt.coreとjdt.uiとjdt.doc、そしてdebug.coreとdebug.uiなどがある）。

　このように分割する理由の1つは、UIコンテンツを提供するプラグインがUIコンテンツ（org.eclipse.ui）を提供しないプラグインとは異なるEclipseの一部をランタイムで必要とするためだ。

■ほかのフィーチャーのインクルード

　Eclipseコンフィグレーションでは、別のフィーチャーによってインクルードされない限り、フィーチャーはルート・フィーチャーとして設定される。デフォルトでは、ユーザーはルート・フィーチャーを「Install/Update」パースペクティブで無効にも有効にもすることができ、「feature.xml」ファイルでアップデートURLを特定することができる。フィーチャーをインクルードする際に検索場所の定義で特に許可のない限りは、ルート・フィーチャーのアップデートURLだけが処理されることになる。

　自分のパッケージの構造は、フィーチャーをインクルードして管理する。複数のフィーチャーを持つこともできるが、ブランドは1つにしか登録できず、ほかのものは構造を提供するか提供プラグインの管理を行う。アップデートサイトを定義するのはルート・フィーチャーだが、selfbothの値と一緒に検索場所属性が使用されたときにインクルードしたフィーチャーが、インクルードされたフィーチャーにこの役割を代行させる場合があることを覚えておきたい。

　Eclipseベースの製品を開発していると、自分のフィーチャーの中にEclipseのフィーチャー・ツリーを入れたくなるだろう。これは製品へのブランド登録に必須の作業ではないものの、代替アップデートサイト（Eclipse自身はhttp://update.eclipse.org/updatesを使用）を指定できたり、アップデートサイトを全く指定せずにWebベースのアップデートを無効にできるようになる。これにより、当該アップデートを自分自身でパッケージングするまで、自分のEclipseベースの製品がアップデートされないようにすることができる。

■オプション・フィーチャーの役割

　フィーチャーを別のフィーチャーの中に含める場合には、そのフィーチャーをオプションに指定することもできる。このような構造を作成する最大の理由は、ユーザー自身が必要に応じて自分が提供したプラグインの一部を無効にできるようにするためだ。

　Eclipseのコンフィグレーションロジックでは、存在しないオプション・フィーチャーをインクルードしている新しいフィーチャーを登録することはできない。つまり、オプション・フィーチャーは適切な必要条件がそろったときに利用できるレイヤを作成するための手段として利用したい。これらのレイヤは異なるディレクトリツリーに置き、それぞれ別のリンクファイルを使いたい。Eclipseのコンフィグレーションにファンクションを登録するときに使うリンクファイルの数に制限はない。

本記事は「IBM developerWorks」に最初に掲載された「Put Eclipse features to work for you “How to use Eclipse features to customize Eclipse behavior”」 をアットマーク・アイティが翻訳したものです。

2/2 　

　INDEX
Eclipseのカスタマイズの勧め（前編）
　 Page1
機能パッケージプラグイン
製品を強く印象づけるプライマリ機能
プラットフォームのコンフィグレーション管理
  Page2
機能を強く印象づけることでランタイム時に自分が提供したプラグインを識別する
PDEを使った機能ビルド戦略
機能の構造化




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

注目のテーマ

Java Agile 記事ランキング

本日 月間
＠IT