JDeveloper統合開発環境(IDE)への拡張機能を開発することで、JDeveloperに追加機能を追加できます。
次の各項では、JDeveloper拡張機能の使用と開発の概要について説明します。
Oracle JDeveloperは、Java、XML、WebサービスおよびSQLの最新の標準を使用してアプリケーションを構築するための統合開発環境(IDE)です。JDeveloperの基本機能の大半は拡張機能(基本のJDeveloper IDEに新機能を追加するソフトウェア・パッケージ)として実装されます。既存の拡張機能をJDeveloperに追加したり、JDeveloperのネイティブ機能をベースに拡張機能を作成したりすることで、自社の開発要件にあわせた新機能を提供できます。たとえば、次のような目的に使用できます。
ワークフローを効率化する。
サードパーティのチーム開発ツールを使用する。
チーム固有のソフトウェア・パッケージを使用する。
監査拡張機能を使用して、開発上の標準やベスト・プラクティスへの準拠を強化する。
ダウンロードしてそのまま使用できる拡張機能も数多く提供されています。これには、Oracle製のものもあれば、サードパーティ製のものもあります。これらを使用することで、JDeveloperに新機能を提供し、その機能を独自の環境内で他のアプリケーションと統合させることができます。たとえば、JDeveloperで利用できるバージョン・コントロールやチーム作業システムの多くは、拡張機能として記述および配布されています。JDeveloperはオープン・アーキテクチャなので、JDeveloper「ヘルプ」メニューの「更新の確認」からダウンロードおよびインストールできます。または、次の場所から拡張機能をインストールすることもできます。
Oracle Technology Network (OTN)のOracle JDeveloper Extensionsページ(http://www.oracle.com/technetwork/developer-tools/jdev/index-099997.html
)
マシンからアクセス可能な場所にあるマニフェストを含む適切に構成されたZIPファイル
注意: JDeveloperに拡張機能をインストールする際には、「ヘルプ」メニューの「更新の確認」を使用することをお薦めします。これにより、使用しているJDeveloperのバージョンに一致する拡張機能バージョンだけが利用可能になります。 |
詳細は、『Oracle Jdeveloperによるアプリケーションの開発』の拡張機能の操作に関する項を参照してください。
また、オープン・アーキテクチャなので、固有のニーズに対応する必要がある場合や、自社の開発チームで使用している外部プロセスやツールにJDeveloperを統合する場合にも、独自の拡張機能を記述できます。メニュー・アイテムの追加、コンテキスト・メニューの作成、JDeveloperツールバーへの機能の組込み、データ・オブジェクトのビューを表示するドッキング可能なウィンドウの作成などを行うことができます。
注意: JDeveloperによる拡張機能の処理方法は、Oracle JDeveloper 11.1.2.nnで変更されました。以前のバージョンのJDeveloperの拡張機能については、ご使用のバージョンのJDeveloperのオンライン・ヘルプを参照してください。 旧バージョンのJDeveloper用のOracle製拡張機能(Extension SDKを含む)および旧バージョンのJDeveloper用のサードパーティ製拡張機能は、Oracle JDeveloper Extensionsページ( 旧バージョンのJDeveloper用に記述された拡張機能の移行については、1.4項「以前のリリースからの拡張機能の移行」で説明しています。 |
JDeveloperのネイティブ機能を使用して独自の拡張機能を開発することもできます。詳細は、第2章「Oracle JDeveloperでの拡張機能の開発」を参照してください。
より高度な開発を行う場合には、JDeveloperの開発チームが開発した、JDeveloper Extension Software Development Kit (Extension SDK)を使用します。これには、サンプル・コードを含んだプロジェクトのコレクションや、拡張機能開発で使用されるクラスやその他の機能への参照を提供するExtension SDK APIについてのjavadoc生成ドキュメントが含まれています。より完全なドキュメントやサンプルが必要な場合には、JDeveloperの「ヘルプ」メニューの「更新の確認」から入手できます。内部チームに広範なサポートを提供する場合や、自社の顧客に提供する製品やサードパーティ製アプリケーションの一部として拡張機能を開発する場合など、高度な拡張機能開発を行う場合には、Extension SDKをダウンロードすることをお薦めします。詳細は、第3章「Extension SDKを使用した開発」を参照してください。
OTNフォーラムのOracle JDeveloperページを使用すれば、拡張機能の開発について質問したり、ディスカッションに投稿したり、他のユーザーと情報を交換できます。OTNフォーラムのOracle JDeveloperページへは、https://forums.oracle.com/forums/forum.jspa?forumID=83
からアクセスできます。
Extension SDKとは対照的に、JDeveloperではコーディングを必要としない外部ツールも使用可能です。次のことが可能です。
コマンドライン・インタフェースを起動できます
パラメータを渡すことができます
JDeveloperにメニューを追加できます
外部ツールの詳細は、『Oracle Jdeveloperによるアプリケーションの開発』のJDeveloperへの外部ツールの追加に関する項を参照してください。
Open Services Gateway Initiative (OSGi)は、Javaランタイム環境上で実行されるサービス・プラットフォームの構築に関する仕様です。JDeveloperはOSGiに準拠する拡張機能のセットとして構築されているため、ユーザーが記述するすべての拡張機能もこの標準に準拠する必要があります。
OSGiの詳細は、http://www.osgi.org
から入手できる、OSGi Service Platform Core Specification Release 4, Version 4.2を参照してください。
OSGiフレームワークは、次の2つの主要な要素に分けられます。
サービス/コンポーネント・プラットフォーム(サービス・プロバイダ、サービス・リクエスタおよびサービス・レジストリ)。
デプロイメント・インフラストラクチャ(実装クラス、リソース、バンドル・メタデータおよびマニフェスト・ファイルを含んだサービス・バンドル)。
サービス/コンポーネント・プラットフォームは、OSGi実装が既存のサービスをアクティブ化、非アクティブ化、更新およびアンインストールしたり、新しいサービスを動的にインストールできるようにするためのものです。
サービス/コンポーネント・プラットフォームは、次の3つのアクター間での対話をサポートしています。
サービス・プロバイダは、特定のサービスを提供し、サービス記述を公開します。
サービス・リクエスタは、サービスを検出し、サービス・プロバイダにバインドします。
サービス・レジストリは、登録されたサービス記述に基づいて、サービスの公開と検出を管理します。
OSGiサービスは、名前と値のペアで構成された可変数の属性(サービス・プロパティ)を持つ、Javaクラスまたはインタフェース(サービス・インタフェース)です。サービス・プロパティは、同じサービス・インタフェースを使用する複数のサービス・プロバイダを区別するのに使用されます。
サービス・レジストリがあることで、サービス・リクエスタはLDAPを使用してサービスを検出できるようになります。
サービス・リクエスタは、イベント・シグナルの変更(たとえば、サービス・レジストリ内にあるサービスの発行または取得)を、通知メカニズムを使用して受信できます。
サービスは、サービス実装クラスおよびリソースを含んだサービス・バンドルにパッケージ化されます。これには、バンドル・メタデータを含んだマニフェスト・ファイルmanifest.mf
も含められます。マニフェスト・ファイルには、サービス名、バージョンおよび依存性などの情報が含められます。
サービス・プロバイダとサービス・リクエスタは、論理エンティティでも物理エンティティでもあるサービス・バンドルの一部です。このバンドルにより、実行時のサービス依存性管理アクティビティが処理されます。アクティビティは次のとおりです。
公開
検出
バインディング
バンドルにバインドされたサービスの動的可用性(受信または送信)に起因する変更への適応。
JDeveloperで作成された拡張機能は、OSGiサービス・バンドル内に含められます。
この項では、拡張機能がJDeveloper内でどのように機能するかについて説明します。拡張機能のロード時には、ユーザーが使用している拡張機能のみがロードされます。これにより、起動時のパフォーマンス、全体的なメモリー使用およびJDeveloperの日常的動作を改善されます。次の説明には、ユーザーによってはあまり馴染みのない用語や概念が含まれています。
JDeveloperユーザーは、自分が作業するロールを選択します。ロールには、そのロールに適用可能な拡張機能のセットが定義されているので、選択したロールによって、どのJDeveloper拡張機能がロードされるかが決定します。たとえば、JDeveloperのデフォルトのロールには、Studio Editionのすべての拡張機能が定義されています。
初期化とは、拡張機能初期化コードAddin.initialize()
を呼び出す操作です。拡張機能の初期化によって、エンド・ユーザーが拡張機能の機能を実行しようとする際、拡張機能が適切に機能するためのあらゆる準備が整えられます。
初期化リストには、以前に初期化された拡張機能が記録されています。このリストを記録しているプロジェクトをユーザーが再度開くと、前回と同じ拡張機能のセットが初期化されます。
トリガー・フックとは、拡張機能の初期化をトリガーするためのメカニズムを提供する、宣言的統合フックのセットです。これらは、拡張機能マニフェストextension.xml
の<trigger-hooks>
セクションに定義されており、JDeveloperの起動時に処理されます。これは、使用する拡張機能が初期化されていない場合でも同様です。
そのため、JDeveloper IDEの起動時に必要となる、拡張機能のすべての情報(関与するギャラリ・アイテム、定義するJavaライブラリ、定義するノード・レコグナイザなど)は、トリガー・フック内に指定されている必要があります。
これに対し、拡張機能マニフェストの<hooks>
セクションは、後で拡張機能が初期化される際に処理されます。
登録とは、拡張機能マニフェストのトリガー・フック・セクションを読み取ってキャッシュする操作です。
遅延初期化とは、トリガー・フックがアクティブ化されるまで初期化されない拡張機能について使用される用語です。
拡張機能のバージョニングは、OSGiによって管理されます。同じ拡張機能に2つ以上のバージョンがある場合、それらは同時にロードでき、その拡張機能がアクティブ化された際には、それに依存するすべての拡張機能もロードされます。OSGiは、特定のバージョンまたはバージョン範囲に応じて拡張機能の状況を処理します。
拡張機能は、それぞれ固有のクラス・ローダー内でクラスロードされます。拡張機能には、他の拡張機能にエクスポートするパッケージのセットが定義されています。OSGiのバンドル・マニフェスト・ファイルには、他のバンドルから利用できるJavaパッケージが定義されています。制限されたクラスへは、リフレクションを使用してもアクセスできません。これは、OSGiが拡張機能のJavaクラス・ローダーを通じてこれらのクラスを保護しているためです。
OSGiサービス・インフラストラクチャは、サービス・プロバイダおよびリクエスタを動的に管理します。
拡張機能には、他の拡張機能への依存性を持たせることができます。拡張機能のロード時には、OSGiバンドル・マニフェストで依存先としてマークされている他の拡張機能もすべてロードされます。これは、JDeveloperで機能のロードをクリックする際には常に起こりうる動作です。たとえば、「アプリケーション・プロパティ」、「プロジェクト・プロパティ」または「プリファレンス」ダイアログでは、以前にアクセスしたことのない機能を起動する場合、関連する拡張機能がロードされるのを待つ必要があります。
JDeveloper拡張機能は、IDE用の標準拡張機能APIを提供する、JSR 198の仕様に準拠しています。詳細は、http://jcp.org/en/jsr/detail?id=198
を参照。
JDeveloperでの拡張機能の処理には、2つのフェーズがあります。
拡張機能の統合。これは、JDeveloperの起動時に実行されます。これは、選択されたロールで使用できるすべての拡張機能を登録する処理です。JDeveloperの起動に必要な拡張機能を除き、拡張機能コードは実行されません。
拡張機能の初期化。これは、拡張機能の登録フェーズ中に拡張機能によって登録された機能領域にユーザーがアクセスする際、毎回実行されます。そのため、JDeveloperの使用中に、拡張機能の初期化は随時実行されます。
拡張機能の登録は、JDeveloper IDEの起動時に実行されるフェーズです。このフェーズでは、利用可能なすべての拡張機能から拡張機能マニフェストextension.xml
の<trigger hooks>
セクションが処理されます。この処理中、拡張機能固有のコードは一切実行されません。ただし、Javaリソース・バンドルなどの変化可能リソースについては例外です。
拡張機能には、<trigger-hook>統合フックを使用して、拡張機能固有のトリガー・フックが定義されている場合があります。その場合、その拡張機能にはoracle.ide.extension.HashStructureHook
ハンドラが使用される必要があります。なぜなら、IDEは拡張機能が初期化されないかぎり拡張機能固有のコードを実行しないからです。拡張機能固有のトリガー・フック・データは、拡張機能レジストリ内で取得できます。トリガー・フックを所有している拡張機能は、その拡張機能が初期化されたときにそのデータを取得できます。詳細は、2.5.1項「<trigger-hook-handler>の登録方法」を参照してください。
これに対し、拡張機能マニフェストextension.xml
の<trigger hooks>
セクションに属さないその他のアイテムは、拡張機能の初期化フェーズで宣言的に初期化されます。
トリガー・フックには2つのタイプ(システムとカスタム)があり、すべての拡張機能は次のいずれかの方法で初期化されます。
システム・トリガー・フックから呼び出される
カスタム・トリガー・フックから呼び出される
すでに初期化されている別の拡張機能によって明示的に初期化される
JDeveloper IDEによって定義されているトリガー・フックのタイプは次のとおりです。
メニュー: 拡張機能へのエントリ・ポイントとして適格なメニューのみをメニュー・トリガー・フックとすることができ、すでに初期化された拡張機能をサポートするために使用されているメニューはトリガー・フックとすることはできません。たとえば、JDeveloperの表示メニューで言うと、メニュー・アイテム「ブレークポイント」はトリガー・フックです。これは、ユーザーがデバッガの実行前にブレークポイントを設定できるようにするためです。これに対し、表示メニューの「デバッガ」サブメニューは、その中のすべてのアイテムが拡張機能の初期化後にのみ使用されるので、トリガー・フックではありません。つまり、初期化されていない拡張機能のメニュー・アイテムは、JDeveloperでは表示されません。
コンテキスト・メニュー: 拡張機能では、コンテキスト・メニューをトリガーとして使用するカスタム・トリガー・フックを作成できます。システムレベルのコンテキスト・メニュー・トリガー・フックはありません。
IDEアクションおよびコントローラ: 登録できるのは、メニュー・トリガー・フックをサポートするためのアクションおよびコントローラのみです。その他すべてのアクションとコントローラは、初期化フェーズで実行する必要があります。トリガー・フック・メニューに登録されたすべてのコントローラでは、それらのメニューが無効化されているかどうかを確認するためのコードを実行できなくなります。メニューをいつ表示するかは、宣言的コントローラ・ロジックを使用して指定する必要があります。
ギャラリ・アイテム: 拡張機能では、ギャラリ・アイテム・トリガー・フックを使用して、JDeveloperの「新規ギャラリ」内のアイテムをリストできます。ユーザーが「新規ギャラリ」からダイアログまたはウィザードを開くと、そのアイテムの拡張機能が初期化され、その拡張機能のOSGiバンドル・マニフェストで依存先としてマークされているすべての拡張機能もロードされます。
テクノロジ・スコープ: プロジェクトにテクノロジ・スコープが追加されると、そのテクノロジ・スコープを登録した拡張機能が初期化され、OSGiバンドル・マニフェストで依存先としてマークされているその他すべての拡張機能も初期化されます。
NodeFactoryレコグナイザ: これを使用することで、拡張機能は自身が所有するノードを識別できます。ノードが「アプリケーション」ウィンドウ内で可視状態になったとき、そのノードの拡張機能が登録されていれば、そのノードは初期化されます。NodeFactoryレコグナイザはまた、デスクトップからJDeveloperへのファイル・ドラッグなどといった操作も処理します。
IDEプリファレンス/設定、アプリケーション・プリファレンス/設定、プロジェクト・プリファレンス/設定: 未初期化の拡張機能は、「プリファレンス」ダイアログ(「ツール」メニューから選択可能)のカテゴリ・リストとしてのみ表示されます。ユーザーがカテゴリをクリックすると、その時点で拡張機能を初期化するかどうかが尋ねられます。
シングルトン登録: シングルトン・クラスは、トリガー・フックとして登録されます。クライアントがシングルトンからサービスをリクエストすると、フレームワークはそのシングルトンの拡張機能が初期化されているかどうかをチェックします。初期化されていない場合は、拡張機能の初期化が要求されます。この例としては、ログ・マネージャが該当します。
注釈: 拡張機能は、注釈トリガー・フックを必要とするように自身を登録できます。その場合、拡張機能には注釈クラス名が定義され、ユーザーがそれらのいずれかの注釈を入力すると、その時点で拡張機能が初期化されます。注釈トリガー・フックは、「アプリケーション」ウィンドウ・ノードの展開時にアイコンのオーバーレイを判断するために使用されます。親ノードが展開されると、フレームワークは登録されている注釈を検索し、見つかった場合は、そのノードに対する適切なアイコンを提供します。ノード・アイコンのオーバーレイが適用された場合、拡張機能は初期化されません。
アプリケーションおよびプロジェクト・マイグレータ: これらのマイグレータは、宣言的に定義される必要があります。マイグレータは、サポートされている現行バージョンを指定します。アプリケーションまたはプロジェクト・ファイルに旧バージョンのマイグレータがリストされているか、いずれのバージョンもリストされていない場合、JDeveloperはその拡張機能のデータを移行するために、拡張機能の初期化をトリガーします。
ライブラリおよびタグ・ライブラリ: ライブラリまたはタグ・ライブラリがプロジェクトに追加されると、関連付けられている拡張機能の初期化がトリガーされます。さらに、プロジェクトが(ロードではなく)開かれると、JDeveloperはそのプロジェクトのライブラリを検索し、それらがまだロードされていなければ、そのライブラリまたはタグ・ライブラリに関連付けられている拡張機能を自動的にロードします。
カスタム・トリガー・フック: 拡張機能では、独自のトリガー・フックを定義できます。これは、クライアントがその拡張機能にプラグインできるようにする場合に便利です。拡張機能でのトリガー・フックの定義は、通常のフック定義と同様の方法で行えます。これを定義すると、クライアント拡張機能は自身の拡張機能マニフェスト内にトリガー・フック登録を追加できるようになります。トリガー・フックを登録する際、拡張機能には、どの拡張機能のロード時にトリガーが発効されるようにするかが指定されます。これらはフックの依存先と呼ばれます。JDeveloperは、フックの依存先としてリストされているすべての拡張機能が初期化されたときにのみ、そのフックを処理します。
拡張機能の遅延初期化は、JDeveloperが起動するたびにすべての拡張機能が初期化されるのを回避する目的で使用されます。
JDeveloperの起動時、IDEは、現在開いているアプリケーションまたはプロジェクト内で、Addinを所有する拡張機能がエンド・ユーザーによって以前に使用されている場合にのみ、Addin.initialize()
コードを実行します。詳細は、2.2.4項「ノード・レコグナイザについて」を参照してください。
各拡張機能は、自身のトリガー・フックに関連付けられているタイプを識別します。これにより、フックに対する次のような処理が可能になります。
開いているアプリケーション・ワークスペースがある場合にのみトリガーできます。
開いているプロジェクトがある場合にのみトリガーできます。
HTTPアナライザなどと同様の方法でいつでも初期化できます。
ユーザーがJDeveloper内のアプリケーションで作業する際、ユーザーによる拡張機能の使用は、プロジェクト固有の拡張機能初期化リストに記録されます。ユーザーがプロジェクトでの作業をやめてJDeveloperを終了し、その後再起動した際、JDeveloperはプロジェクトの初期化リストに記録された拡張機能のみを初期化します。
プロジェクトを必要としない拡張機能の場合、この情報はそのユーザーのIDEプリファレンス内に格納されます。
拡張機能を開発する際には、統合ポイントで遅延初期化がどのように処理されるかを考慮する必要があります。次に例を示します。
拡張機能では、統合ポイントが静的であることを前提にすることはできません。拡張機能は、そのライフサイクル中、自身の統合ポイントに関連付けられた新しいデータを、いつでも処理および統合できる必要があります。
たとえば、拡張機能Aに、他の拡張機能がリスナー・クラスを登録できるようにするためのAPIまたはカスタム拡張機能フックがあるとします。その場合、拡張機能Aでは、それらすべてのリスナーが拡張機能Aの初期化よりも早い時点で登録されることを前提にすることはできません。Aに依存する他の拡張機能は、ABCのライフサイクル内のより遅いタイミングで遅延初期化される可能性があります。したがって拡張機能Aは、それらのリスナーに関連付けられたイベント起動コードを更新して、拡張機能の遅延ロードの結果に対応する必要があります。これを行う具体的な方法については、次の点で説明します。
拡張機能では、oracle.ide.extension.HashStructureHook
を使用してカスタム統合フックを実装する必要があります。このフック処理クラスには、新しい追加データがいつ登録されたかをクライアントがわかるようにするための、プロパティ変更リスナー・メカニズムがあります。拡張機能に、これらのプロパティ変更イベントをリスニングさせる必要があります。
深い依存関係ツリーを設定することは避ける必要があります。なぜなら、これによって依存先のすべての拡張機能が初期化され、拡張機能の遅延ロードによるパフォーマンス効果が弱まる可能性があるからです。拡張機能の依存関係ツリーが深いことに気づいた場合は、拡張機能をリファクタリングして、依存先の拡張機能の数を減らす必要があります。詳細は、2.2.6項「大規模な拡張機能について」を参照してください。
旧バージョンのJDeveloper用に開発した拡張機能がある場合は、現行リリースのJDeveloperで実行できるように変更を加える必要があります。1.3項「JDeveloper拡張機能の仕組み」では、現行リリースのJDeveloperで拡張機能がどのように機能するかが説明されています。最初に、ここで説明されている概念について理解することをお薦めします。
考慮する必要があるコーディング領域は次のとおりです。
Addin.initialize
メソッドは、IDEの起動時に呼び出されなくなりました。トリガー・フックを使用して拡張機能を初期化する必要があります。トリガー・フックは、拡張機能マニフェストextension.xml内で定義されます。JDeveloper IDEによって定義されているトリガー・フック・タイプのいずれかを使用することもできますし、カスタム・トリガー・フックを作成することもできます。詳細は、2.5項「トリガー・フックの定義および使用方法」を参照してください。
拡張機能マニフェストextension.xml
内のほぼすべての<hooks>
プロパティは、<trigger hooks>
内に配置されるようになりました。
旧バージョンのJDeveloperでは、ロール・ファイルは排他的に使用されていたため、デフォルトではすべての拡張機能がロードされ、ロードしないものはロール・ファイルによってJDeveloperに伝えられていました。現行バージョンでは、ロール・ファイルは包含的に使用されるようになったため、ロールに定義されている拡張機能だけを、そのトリガー・フックのアクティベート時にロードできるようになりました。
すべての拡張機能が個別のクラス・ローダーを持つようになりました。その結果、パッケージ保護されたメソッドを、同じパッケージ内の異なる拡張機能のクラスから呼び出すメソッドは機能しなくなりました。
拡張機能にカスタム統合ポイントがある場合は、それらに変更を加えて、オンデマンドの拡張機能初期化を処理できるようにする必要があります。詳細は、1.3.3項「遅延初期化の仕組み」を参照してください。
リフレクションを使用して、明示的依存関係を持たない拡張機能内のクラスを初期化するコードは、機能しなくなりました。
2.2項「拡張機能開発のユースケース」には、拡張機能を変換して、遅延初期化をサポートする宣言的トリガー・フックを使用できるようにする場合の、よく起こる状況を示すユースケースが多数記載されています。
JDeveloperのネイティブ機能を使用して拡張機能を作成する場合(第2章「Oracle JDeveloperでの拡張機能の開発」を参照)も、Extension SDKをダウンロードして拡張機能を開発する場合(第3章「Extension SDKを使用した開発」を参照)も、最初に行うことは、JDeveloperで、拡張機能開発用に構成された1つ以上のアプリケーションとプロジェクトを作成することです。
アプリケーションは、1つ以上のプロジェクトに対する制御構造です。プロジェクトは、プログラムまたはプログラムの一部を定義する一連のファイルの論理コンテナです。詳細は、『Oracle Jdeveloperによるアプリケーションの開発』の「アプリケーションとプロジェクトの操作について」を参照してください。
アプリケーションとプロジェクトを作成するには、次のようにします。
「ファイル」→「新規」を選択して「新規ギャラリ」を開きます。
「新規ギャラリ」の「カテゴリ」ツリーで、「一般」の「アプリケーション」を選択します。
「アイテム」リストで、「拡張機能アプリケーション」をダブルクリックします。拡張機能アプリケーションの作成ウィザードが開きます。ウィザードのヘルプを参照するには、[F1]を押すか「ヘルプ」をクリックします。
アプリケーションの名前を入力し、場所とアプリケーション・パッケージ接頭辞を選択して、「次へ」をクリックします。拡張機能開発用に構成されるプロジェクトは、Extension
というデフォルト名を持っています。必要に応じて、プロジェクト名を変更し、「次へ」をクリックします。
Java設定の構成ページで、デフォルト・パッケージ、Javaソース・パスおよび出力ディレクトリを設定できます。必要な変更加えて、「次へ」をクリックします。
拡張機能設定の構成ページで、拡張機能のオプションを設定できます。
図1-1に示すように、「アプリケーション」ウィンドウ内に拡張機能プロジェクトが作成され、その中に各要素が含められます。
拡張機能プロジェクトは、拡張機能マニフェストextension.xml
およびOSGiマニフェストmanifest.mf
のコピーとともに作成されます。拡張機能マニフェストは概要エディタで開かれます。
なんらかの理由で、拡張機能アプリケーションを直接作成しない場合は、カスタム・アプリケーションを作成して、ウィザードの「プロジェクト」ページでプロジェクト機能として「拡張機能の開発」を選択することができます。
異なるJDeveloperバージョン用の拡張機能を開発する場合は、拡張機能アプリケーションの作成時にプラットフォームを選択します。
注意: JDeveloperの複数のリリースに対しては、それらのバージョンが両方とも同じメジャー・リリースのマイナー・リリースである場合のみ、拡張機能を開発できます。たとえば、JDeveloperバージョン11.1.2. JDeveloperの拡張機能の記述方法は、JDeveloper 11gリリース11.1.2. |
拡張機能が対象とするJDeveloperバージョンを選択するには:
拡張機能アプリケーションを作成します。1.5.1項「拡張機能開発用のアプリケーションおよびプロジェクトの作成方法」を参照してください。
拡張機能設定の構成ページで、異なるターゲット・プラットフォームを選択します。必要に応じて、をクリックし、「拡張機能プラットフォームの管理」ダイアログでプラットフォームを選択します。詳細は、[F1]を押すか、ダイアログ内で「ヘルプ」をクリックしてください。
アプリケーションとプロジェクトを作成したら、拡張機能の開発を開始できます。
JDeveloper IDEでの開発を継続する場合(たとえば、拡張機能Addin
を作成する場合など)は、2項「Oracle JDeveloperでの拡張機能の開発」を参照してください。
Extension SDK内のサンプルを使用して拡張機能を作成する場合やExtension SDK APIを使用する場合は、第3章「Extension SDKを使用した開発」を参照してください。
拡張機能マニフェストextension.xml
は、拡張機能の様々な性質を制御します。拡張機能をデプロイする前に、extension.xml
を完成させて、トリガー・フックの登録などを済ませる必要があります。extension.xml
は、1つのプロジェクトにつき1つのみ作成でき、常にMETA-INF
というディレクトリ内に置く必要があります。
拡張機能マニフェストは、JSR-198仕様(http://jcp.org/aboutJava/communityprocess/final/jsr198/index.html
から入手可能)に準拠しています。
フックおよびトリガー・フックは、拡張機能マニフェストの関連セクション内に設定されます。extension.xmlの<hooks>
セクションは、拡張機能が初期化される際に処理されます。<trigger-hooks>
セクションは、JDeveloperの起動時に処理されます。
JDeveloperには、extension.xml
専用の概要エディタがあります(図1-2を参照)。
extension.xml
の編集は、概要エディタを使用して行います。このエディタでは、依存関係などに関する詳細情報を各フィールドに入力したり、利用可能なオブジェクトのリストからオブジェクトを選択でき、また、「構造」ウィンドウや「プロパティ・インスペクタ」を使用することもできます。概要エディタでは操作できないextension.xml
の情報を編集するには、「構造」ウィンドウを使用するか、extension.xml
のソース内で作業します。ソースにアクセスするには、「ソース」タブをクリックします。
依存関係に関する詳細は、1.7.1項「依存関係について」を参照してください。
拡張機能プロジェクトを作成して作成されたextension.xml
のテンプレート・コードには、例1-1に示すように、主要要素のプレースホルダが記述されます。
例1-1 extension.xml内のテンプレート・コード
<extension id="extension" version="1.0.0" esdk-version="2.0" rsbundle-class="extension.Res" xmlns="http://jcp.org/jsr/198/extension-manifest"> <name>${EXTENSION_NAME}</name> <owner>${EXTENSION_OWNER}</owner> <trigger-hooks xmlns="http://xmlns.oracle.com/ide/extension"> <!-- TODO Declare triggering functionality provided by extension: extension --> <triggers/> </trigger-hooks> <hooks> <!-- TODO Declare functionality provided by extension: extension --> </hooks> </extension>
extension.xmlの概要エディタは、拡張機能マニフェストextension.xml
とOSGIマニフェストmanifest.mf
を宣言的に更新します。
extension.xml
の概要エディタの「一般」タブでは、拡張機能に関する情報(拡張機能名、SDKバージョンなど)を入力したり、アイコンや著作権情報などの機能を指定します。これらの情報は、feature-hook
およびplatform-info
要素に移入されます。
「ランタイム」タブはmanifest.mf
を更新し、ランタイム値を指定できます。
「依存性」タブでは、その拡張機能を別の拡張機能の一部として指定したり、別の拡張機能の親として指定したりできます。これらの情報は、dependencies
要素に移入されます。「フック」タブでは、拡張機能の機能に関連する、追加の拡張機能の詳細情報を入力します。詳細は、1.7.1項「依存関係について」を参照してください。
拡張機能のIDEへのバインド方法を指定するには、「フック」タブを使用します。
「フック・ハンドラ」タブを使用すると、他の拡張機能が統合ポイントとして使用できる、拡張機能のトリガー・フックを定義することができます。
各フィールドの内容に関する詳しいヘルプを参照するには、概要エディタの任意のタブから[F1]を押します。
OSGiマニフェストMANIFEST.MF
には、拡張機能バンドルがエクスポートするパッケージがリストされます。MANIFEST.MF
は、1つのプロジェクトにつき1つのみ作成でき、常にMETA-INF
というディレクトリ内に置く必要があります。
OSGiマニフェストはソース・エディタで編集できますが、概要エディタで宣言的に編集することをお薦めします。詳細は、1.6.1項「概要エディタでの拡張機能マニフェストの編集」を参照してください。
新しい拡張機能プロジェクトが作成されると、デフォルトのMANIFEST.MF
が作成されます。初期コンテンツを例1-2に示します。
例1-2 デフォルトのMANIFEST.MF
Bundle-ManifestVersion: 2.0 Bundle-Version: 1.0.0 Bundle-SymbolicName: extension Bundle-ClassPath: . Require-Bundle: oracle.ide
OSGiマニフェストのコンテンツの詳細は、http://www.osgi.org
を参照してください。
JDeveloperは、パッケージ化プロセスの一部としてmanifest.mf
を更新し、次のものを提供します。
必須バンドル: 自分の拡張機能に必要な、別のOSGiバンドルのクラスがリストされます。拡張機能マニフェスト内のrequire-bundles
要素から取得されます。
エクスポート・パッケージ: 拡張機能内のJavaパッケージを他の拡張機能から利用できるようにする場合に、それらのパッケージがリストされます。
バンドル・クラスパス: 拡張機能から、OSGiバンドルではないJARのクラスを参照する必要がある場合に、それらがリストされます。拡張機能マニフェスト内の<dependencies>
要素から取得されます。
これらの値は、OSGiバンドル・プロファイル・ダイアログで使用されます。詳細は、5.2.1項「デプロイメント・プロファイルの作成方法」を参照してください。
拡張機能は、他の拡張機能やJARファイルに依存できます。JDeveloper用の拡張機能を開発するには、拡張機能への依存と、拡張機能ツリーについて理解する必要があります。自分の拡張機能と他の拡張機能との間に、次のどの依存関係があるかを知る必要があります。
自分の拡張機能が別の拡張機能の一部になっている
1つ以上の拡張機能が自分の拡張機能の一部になっている
また、追加する必要があるライブラリおよびJARファイルも把握する必要があります。たとえば、oracle.jdeveloper.maven.jar
への依存関係を追加した場合は、外部Mavenモジュールを使用して提供されるJARファイルのライブラリも追加する必要があります。
これらが把握できたら、拡張機能マニフェスト内に依存関係を設定して、必要なライブラリと追加JARファイルが拡張機能バンドルの一部になるようにします。
拡張機能プロジェクトを作成すると、拡張機能マニフェストが作成され、概要エディタで開かれます。詳細は、1.6項「拡張機能マニフェストの操作」を参照してください。
拡張機能がロードされる順番は、拡張機能マニフェスト内のエントリによって決まります。
拡張機能マニフェストに依存関係を設定するには、次のようにします。
必要であれば、「アプリケーション」ウィンドウでMETA-INF
の下のextension.xml
をダブルクリックして、extension.xml
を概要エディタで開きます。「依存性」タブを選択します。
他の拡張機能がこの拡張機能に依存するように指定するには、「インポートされたパッケージ」セクションを使用します。
作業中にヘルプを表示するには、[F1]を押すか、ダイアログから「ヘルプ」をクリックします。
選択した拡張機能が、拡張機能マニフェストの<dependencies>
セクションに、<import>
要素としてリストされます。
拡張機能が他のOSGiバンドルのクラスを必要とするように指定するには、「必須バンドル」セクションを使用して、この拡張機能に依存する1つ以上のバンドルを指定します。
選択した拡張機能が、拡張機能マニフェストの<require-bundles>
セクションに、<bundle>
要素としてリストされます。クラスを検索する際、OSGiはそれらをリスト順に検索するので、バンドルは必ずバンドル・リスト内の適切な場所に追加してください。
拡張機能をパッケージ化する際には、生成されるバンドル・マニフェストの決定に使用される、OSGiバンドル・プロファイルを作成します。詳細は、5.2.1項「デプロイメント・プロファイルの作成方法」を参照してください。
OSGiバンドル・プロファイル・ダイアログで指定する重要なエントリは次のとおりです。
パッケージ・エクスポート: ここでは、生成されるバンドル・マニフェストのExport-Packageセクションに影響するファイル・グループを指定します。たとえば、拡張機能内に、他の拡張機能からアクセスできるようにするJavaパッケージがある場合は、それらのパッケージをこのセクションにリストします。
パッケージ・インポート: ここでは、生成されるバンドル・マニフェストのImport-Packageセクションに影響するファイル・グループ、ライブラリ依存関係およびプロファイル依存関係を指定します。
必須バンドル: ここでは、生成されるバンドル・マニフェストのRequire-Bundleセクションに影響するライブラリ依存関係とプロファイル依存関係を指定します。
ライブラリの依存性ページでは、バンドルのライブラリ依存関係をチェックできます。プロファイルの依存性ページでは、アプリケーション内の他のJARデプロイメント・プロファイルを調べたり、必要であればそれらを変更できます。