6月25日にリリースされたEclipse Ganymede（Eclipse 3.4）(source)のリリースにあわせてInfoQはEclipseの一連のサブプロジェクトを取り上げていく。今回取り上げるのはバージョン3.4がリリースされようとしているPDE(source)（Plugin Development Environment）だ。InfoQはPDEの技術主任でCode9の一級コンサルタントでもあるChiris Aniszczyk氏に(source)PDEとそれがもたらすことについて話を聞いた。
Aniszczyk氏が語ったPDE 3.4での新機能および更新点には次のことが含まれる。
- APIツーリング － APIツーリング（作成機能）ではAPIの使い方やバイナリ互換性でのエラーをワークスペース内で表示するAPIツールを作成できます。このためには APIツールがエラーを表示できるようにプロジェクトを設定し、ワークスペースにあるプロジェクトを比較する基となるAPI基準を設定しないといけません。たとえば、Eclipse 3.4のリリースのため、PlatformチームはAPIを3.4で開発する場合のためにEclipse 3.3.2での基準を設定するのにAPIツールを使いました。APIツールは互換性のエラーや@sinceタグの抜け、正しくないバージョン番号、その他ふつうは手作業でチェックしないといけない多くのAPIに関する事柄を知らせてくれます。この素晴らしいことがワークベンチ内で起きるようになると、開発しながらエラーを見つけることができます。しまった、インターフェースにひとつメソッドを追加したのにバージョン番号を変えるのを忘れてた。そんな時に APIツールはクイックフィックス機能を使ってあなたを助けてくれます。APIツーリングのwiki（API Tooling wiki）ではもっと詳しいことを知ることができます。
- オープン・プラグイン・アーティファクト － Eclipseを使っている人であればほとんどがJDTのすばらしいオープンタイプのショートカット（Ctrl+Shift+T）を使ったことがあるでしょう。私たちも似たようなことをPDEですることにしました。それがオープン・プラグイン・アーティファクト（Ctrl+Shift+A）で、これを使うとすばやくプラグイン、拡張機能、拡張ポイント、エクスポートされているパッケージにジャンプすることができます。ぜひ一度試してみてください。気に入ってくれること受け合いですよ！私は今毎日使ってます！
- ユーザアシスタンスツーリング － 自分のEclipseアプリケーション内でユーザアシスタンスが使えるようにするのが好きな人にとって、PDEに新しい目次エディタとHelp Contextエディタがあるというニュースは嬉しいことだと思います。それらのファイルを直接するのでなくナイスなエディタを使うという選択肢が手に入ったのです。その上3.4ではCheat Sheetエディタも改善しています。
- プラグインスパイ(source) － これは私がSDKに含まれている機能を再利用したいために探したり、今選択しているクラスを探したりした時に経験した私自身のイライラから生まれたものです。たとえば、もしあなたがあるRCP（Rich Client Platform）プロジェクトに携わっていて、あなたのアプリケーション内でログビューを再利用したいとします。これまでなら、コードや拡張機能を探し回ってそれらのIDやその他もろもろを見つける必要がありました。このプラグインスパイによって、ただワークベンチから何を使いたいか選択するだけでこの手間を回避し、それについての有益な情報を得ることができます。今回の場合だと、ログビューを選択してプラグインスパイを起動します。すると今選んでいたビューを実装している本体のクラス、どのプラグインにそのクラスが含まれているか、今選択している部分のクラスは何かなどの情報を得ることができます。
- プラグインレジストリ － このPDEのビューは実行中のアプリケーションの状態をすばやく見ることができます。たとえば、今アクティブだったり動いていたりするプラグインや、そうでないプラグインを見ることができます。またそれらプラグインで利用可能な拡張機能や拡張ポイントを見て調べることもできます。3.4では「他の操作も表示する」というコンセプトもこのビューに加えました。他の手順を踏まないでもビューだけでバンドルを開始・終了したり詳しく見ることができます。もし Eclipseベースのアプリケーションの状態をすばやく見るためのビューがほしいと思ってるのでしたら、このビューがうってつけです。
PDEをEclipseプラグイン以外のものを作るのに利用することについて聞くと、Aniszczyk氏はこう述べた。
ここ何回かのリリースで、PDEはOSGi仕様のスタンドアローンアプリケーションを作る機能を備えました。しかしそれを広く知ってもらう方法を誤ってしまいました。これは「プラグインプロジェクトの新規作成」ウィザードに隠れているのですが、ここで対象とするEclipseのバージョンやOSGiフレームワークを指定することができます。ネーミングについて紛らわしいのも問題だと思いますが、そうですよね？Eclipseではプラグインという言葉を使いますが、OSGiのコミュニティではバンドルという言い方をします。PDEのある部分では、これに対処しようとしていますが、まだそこまで至っていません。たとえばプラグインプロジェクトを新規作成し、OSGi環境をターゲットに指定すると、OSGiフレームワークの初期設定でプラグインではなくバンドルという言葉を使っていることに気付くと思います。そうだ、PDEの3.5ではDeclarative Serviceのための支援機能を計画しているのですが、これをOSGiコミュニティが知ればPDEに興味を持ってくれるかもしれませんね。今PDEインキュベータではエキサイティングな作業（work）をいくつか行っているところです。
Aniszczyk氏はPDEでOSGiアプリケーションを作ることについてさらに詳細を語ってくれ、Eclipseのバージョンを指定するのと同じ方法でOSGiフレームワークを指定でき、バージョンの異なるEclipseについてだけでなくスタンドアローンのOSGiアプリケーションについてのテンプレートも用意されていると言った。PDEではクラスパスを管理したりや既存のEclipse開発ツールを使うことができるためOSGi開発を容易にするとAniszczyk氏は述べる。PDEは Equinoxもデフォルトでサポートし、KnopflerfishやFelixといった他のOSGiフレームワークに対する拡張ポイントも提供する。 Aniszczyk氏は様々なOSGiフレームワークのディベロッパと一緒になって彼らの要望をPDEへ取り込むような作業を行いたいという希望を語った。そしてPDEチームはいつでも参加したいと望む人たちを助けたいと思っているとも語った。
Aniszczyk氏はPDEコミュニティについても語り、特に立ち上げの助けとなったBug Dayについて語った。Bug Dayからは100以上のバグフィックス(source)がPDEに寄せられと言い、またPDEチームがほんの少しだけIRCを使って手助けするだけでコミュニティが行ってくれることの大きさに驚きを表していた。Aniszczyk氏はコミュニティのメンバがPDEを手伝う一番の方法は、Bug DayのBugzillaにあるバグリスト(source)に目を通して協力してみたいという意思を表に出してみることだとも語った。まずそこから始めてもらえば、PDEチームは喜んでIRCやSkypeで力添えするそうだ。このことはPDEのモットーである「私たちがしているのはツールで便利にすることだが、私たちが考えているのは人である」に通じている。
e4（Eclipse 4）との統合あるいは影響はどうか尋ねると、Aniszczyk氏はこう述べた。
PDEはE4の影響を強く受けています。E4が注目されるのはプラットフォームを築くからですが、プラットフォームは結局ツール機能を必要とすることをみんな知っています。私たちが今E4について調べていることには2つの方向性があります。
- マルチ言語プラグイン － 現状では、すべてのプラグインがJavaで書かれています。E4では、JavaScriptのような他言語も視野に入れたり、ウェブをターゲット環境に入れたりするのも焦点のひとつになっています。EclipseのプラグインをJavaScriptやGroovyやScalaのような他の言語で書くのはずっと私の夢でした。これを実現するために、PDEはみなさんにとってよりプラットフォームとしての成長を始めています。今のところPDEにはマルチ言語のプラグインを実現するためのものはありませんが、そのためにはランタイムでのサポートが必要となります。
- ひとつのソースと複数の対象プラットフォーム － Eclipseを使っていてプラグインも作っている人ならおそらくターゲットプラットフォームの概念には慣れているでしょう。PDEでのターゲットプラットフォームは開発対象となるプラグインの集まりを表します。たとえば、通常開発対象となるのは今動かしているものです。しかしE4ではウェブやデバイス、その他にもあるかもしれませんが、そういった様々な環境を対象とする機能が備わります。私が伝えたいことを知ってもらうには、Eclipseの EBERT（Eclipse Business Experience Report Tool）の例(source)を見てもらえばいいでしょう。これはEclipse Rich Client Platform（RCP）(source)やEclipse Rich Ajax Pltform（RAP）(source)や組み込みRich Client Platform（eRCP）(source)を使って、クライアント/サーバ/組み込みデバイスのそれぞれでEclipseベースのアプリケーションを実行可能にしています。PDEでこのようなアプリケーションを開発するプロセスは若干異なります。というのも、対象となるプラットフォームはワークスペースによるからです。そのため対象とするプラットフォームごとに、それに対応するプラグインの集まりへターゲットプラットフォームをスイッチする必要があります。E4では、JREをプロジェクトレベルで対象となる変えられるのと同じように、PDEでもプロジェクトレベルごとに対象を設定できるようにすることを目指しています。
- プロビジョニング（（必要に応じて必要なものを供給する仕組み） － Eclipseが刷新した更新プラグインであるProvisioning Platform（p2）を手にした今、そこには素晴らしいツール機能を生み出す大きなの可能性があります。PDEチームは、旧来の更新システムを利用していた既存のツール機能を3.4でp2が認識できるように苦労して変更しました。E4（3.5もですが）に向けての次のステップはツール機能をp2が認識できるだけでなく、p2システムともっと連携して今までできなかったことをできるようにすることです。たとえば、更新サイトを作る現在の方法でなく、ボタンを押すだけで更新を公開できることを考えてみてください。あるいはプラグインを右クリックするだけで好きなところ、それは今それを表示しているワークベンチかもしれませんし、今実行しているアプリケーションかもしれませんが、どこにでもデプロイすることができることを思い描いてみてください。E4そして 3.5では、p2が便利にしてくれる分野で素晴らしいことが起こることを期待していいと思います。
最後に、E4とPDEではエキサイティングな活動がたくさん行われるようになります。私は口癖のように言っているのですが、とてもクールなものを作ることができても素晴らしいツール機能がないとなかなか受け入れられないのです。
原文はこちらです：http://www.infoq.com/news/2008/06/eclipse-ganymede-pde