| Oracle WebCenter Framework開発者ガイド 10g（10.1.3.2.0） E05044-04 |
|
 戻る |
 次へ |
この章では、Oracle JDeveloperおよびCVS（統合ソース制御システム）を使用してOracle WebCenter Suiteプロジェクトの作業を行うためのアドバイスを記載します。この章を読む前に、『Oracle Application Development Framework開発者ガイド』で、CVSを使用したチーム開発に関する章をお読みください。
WebCenterアプリケーションでCVSを使用することは、ソース制御システムを使用する他のあらゆる開発環境と類似します。ただし、これはOracle Application Server Portal（OracleAS Portal）で使用されるインプレース編集パラダイムとはまったく異なります。Oracle JDeveloperのオンライン・ヘルプ・システムおよび『Oracle Application Development Framework開発者ガイド』で、CVSの詳細を入念に確認してください。
はじめに
CVSで制御するアプリケーション・ファイルのソースがまだ存在していない場合は、開始する前に、アプリケーション・ファイルをCVSにインポートする必要があります。アプリケーション・ファイルをCVSにすばやくインポートする手順は、次のとおりです。
Oracle JDeveloperを開きます。
「表示」、「CVSナビゲータ」の順に選択して、CVSナビゲータを起動します。
アプリケーション・ナビゲータでアプリケーションを選択し、「バージョニング」で「モジュールのインポート」を選択します。すでにCVS接続がある場合は、直接CVSへのインポート・ウィザードが表示されます。まだCVS接続がない場合は、次の手順で接続を作成するように要求されます。
「接続の作成の確認」ダイアログ・ボックス（図11-1）が表示されたら、「OK」をクリックします。
ウィザードの「ようこそ」ページが表示されたら、「次へ」をクリックして「接続」ページを表示します。
「接続」ページ（図11-2）で、CVSの接続情報を入力します。
「次へ」をクリックします。
「ルート」ページ（図11-3）で、「CVSROOTの値」を入力します。
「次へ」をクリックします。
「テスト」ページ（図11-4）で、「接続のテスト」をクリックします。図11-5に示すような「CVSにログイン」ダイアログ・ボックスが表示されます。
パスワードを入力し、「OK」をクリックします。
テストが成功した場合、図11-6に示すようなページが表示されます。
「次へ」をクリックします。
「名前」ページで、「接続名」の値を入力します。デフォルト名はCVSROOTという値ですが、図11-7に示すように、より説明的な名前に変更できます。
「終了」をクリックします。CVSへのインポート・ウィザードが表示されます。
ウィザードの「ようこそ」ページで「次へ」をクリックして、「モジュール」ページを表示します。
「モジュール」ページで、リストから「接続名」を選択します。
図11-8に示すように、新しいモジュールの「モジュール名」を入力します。
「次へ」をクリックします。
「タグ」ページで、プロジェクトの作成用のタグ名を指定します。図11-9に示すように、この例では、デフォルトの値をそのままにしておきます。
「次へ」をクリックします。
「ソース」ページでは、アプリケーションの場所を指定します。図11-10に示すように、この例では、デフォルト値をそのままにしておきます。
「次へ」をクリックします。
「フィルタ」ページでは、インポート操作からファイルを除外するためのフィルタを指定します。図11-11に示すように、この例では、デフォルトのフィルタをそのままにしておきます。
「次へ」をクリックします。
「オプション」ページでは、新しく作成したモジュールをすぐにチェックアウトしてプロジェクトのバージョニングを開始するかどうかを指定できます。図11-12に示すように、この例では、デフォルトの選択項目をそのままにしておきます。
「次へ」をクリックします。図11-13に示すように、このインポート操作に対して選択した設定の概要が、確認のために表示されます。
「終了」をクリックして、インポート操作を実行します。これで、チームの他のメンバーが、新しく作成したモジュールをチェックアウトして変更をコミットできるようになります。
ソース制御システムを使用するうえで最も重要な局面の1つは、特定のアクションがどのファイルに影響を及ぼすかを理解することです。これがわかっていないと、プロジェクトに対して実行するアクションでチェックインまたはチェックアウトするファイルの数を間違えて、ソースを誤って破損する可能性があります。この項のヒントは、WebCenterアプリケーションの構築時に実行する主要なアクションに必要なファイルについて理解することを目的としています。
WebCenterアプリケーションで使用する主要なオブジェクトは、次のとおりです。
ページ
ポートレット
プロデューサ
データ・コントロール
これらの各オブジェクトは、異なる複数のメタデータ・ファイルで構成された非常に複雑なオブジェクトです。ページ・メタデータ・ファイルの詳細は、『Oracle Application Development Framework開発者ガイド』を参照してください。ポートレットおよびプロデューサのメタデータ・ファイルの詳細は、付録C「WebCenterアプリケーションのファイル」を参照してください。
表11-1に、主要な開発者アクションと、これらのアクションの影響を受けるファイルをリストします。CVSでファイルを管理するときは、この情報を考慮してください。
表11-1 開発者アクションの影響を受けるファイル
| アクション | 影響を受けるファイル |
|---|---|
|
プロデューサの登録 |
|
|
プロデューサの登録解除 |
プロデューサはアプリケーションから削除されます。ただし、CVSからメタデータ・ファイルを手動で削除する必要があることがあります。これ以外の要素はすべて、 |
|
ページへのポートレットの配置 |
Oracle ADF Facesコンポーネント（ポートレットなど）をページに追加するたびに、 Oracle ADF Facesコンポーネントをページに追加するたびに、 |
|
ページからのポートレットの削除 |
ページ上にポートレットを配置する場合と同じファイル。 |
プロジェクトの管理者が、共通の開発者要件を1回で実装してから、全員が使用できるようにそのバージョンをチェックインすることが実践原則となります。前もって計画し、管理者がこれらの共通要件を考慮しておくことで、冗長的な作業やエラーを削減できます。
たとえば、2人の開発者が、アプリケーションの別々のページにOmniPortletを追加する必要があるとします。この場合、プロジェクト管理者がすでにOmniPortletプロデューサを登録していれば、両方の開発者がこのプロデューサをすぐに使用できます。まだ登録していないと、各開発者が別々にOmniPortletプロデューサを登録することにより、不要な重複と混乱を招く可能性があります。
あるいは、多数の開発者が、同じOracle Content Databaseリポジトリからのコンテンツを使用する必要があるとします。この場合は、最初に1人が必要な接続を設定してチェックインする必要があります。その後、その他の開発者は同じデータ・コントロールを再利用するだけです。
チーム開発で作業する場合は、プロデューサに関する次の考慮事項に留意してください。
プロジェクトに対してEARファイルを構築する場合、個々のプロジェクトではなくアプリケーション全体に対して接続がロードされます。たとえば、P1およびP2という2つのプロジェクトを持つアプリケーションがあるとします。P1には100個のプロデューサが登録されており、P2にはプロデューサは登録されていません。この場合、どちらかのプロジェクトに対してEARファイルを構築すると、P1のプロデューサ接続の100個全部がconnections.xmlにロードされます。ただし、手動でconnections.xmlを編集することもできますので覚えておいてください。
デプロイ前ツールを実行してターゲットのEARファイルを作成する場合、connections.xml内のすべての接続にアクセスできる必要があります。このため、この例では、P1の100のプロデューサ接続のいずれかがなんらかの理由で使用不可能になった場合、どちらのプロジェクトのターゲットのEARファイルの生成も失敗します。全体の開発作業をアプリケーションおよびプロジェクト別に分担するときは、この動作を考慮して、慎重に計画する必要があります。
Oracle WebCenter Frameworkでは、同じ名前で2つのプロデューサを登録できますが、一般にこのような状況は避けたほうが賢明です。たとえば、同じアプリケーションで作業している2人の開発者が、誤ってプロデューサを同じ名前で登録した場合、通常は、プロデューサ名の1つを一意の名前に変更することがベストです。2つのプロデューサが同じ名前で登録されている場合、プロデューサに対してエラーのデバッグや管理タスクを実行する際に、両者を区別することが非常に難しくなります。
場合によっては、複数の開発者でポートレットを構築し、最終的にこれらのポートレットを1つのプロデューサの下に結合する必要があります。この目的を達するには、開発者がいくつかの潜在的な問題を理解している必要があります。
ポートレット名とJSPパスは、クラッシュする可能性があります。あるアプリケーションで1つのプロデューサ内にポートレットを結合する場合、ポートレット開発者は、ネーミングのクラッシュを回避するために、事前に準備したクラス・パッケージ名およびJSPパスを使用する必要があります。
ポートレット・ウィザードでJPSポートレットを作成するとき、ポートレット・モードのディレクトリはデフォルトでportletn\html\mode_nameに設定されています。ここで、nは、ポートレットを作成するたびに1ずつ増える数です。ディレクトリおよびファイル名のクラッシュを回避するために、ポートレット開発者は、ポートレット・ウィザードの「コンテンツ・タイプとポートレット・モード」ページでディレクトリ名を変更する必要があります。ポートレット・モードを選択してから、対応するフィールド内のディレクトリ名を一意の名前に変更します。
ポートレットを1つのプロデューサ内に結合するとき、ポートレット・ディスクリプタ・ファイルを手動でマージする必要があります。このとき、次のようにして識別子のクラッシュを回避します。
portlet.xmlおよびoracle-portlet.xmlファイル内のJPSポートレット識別子は、portlet1から始まって順に自動生成されます。複数のポートレット・ディスクリプタ・ファイルを手動で1つにマージするとき、他のポートレット識別子とクラッシュするポートレット識別子はすべて変更する必要があります。
同様に、provider.xml内のPDK-Javaポートレット識別子は、1から始まって順に自動生成されます。複数のprovider.xmlファイルを手動でマージするとき、他のポートレット識別子とクラッシュするポートレット識別子はすべて変更する必要があります。
また、Webディスクリプタ（web.xml）の変更内容（セキュリティ・ロール情報など）も手動でマージする必要があります。
PDK-Javaポートレットの場合は、.propertiesファイルも手動でマージする必要があることがあります。
開発者が認可エディタを使用してページまたはコンポーネント（イテレータやデータ・コントロールなど）のポリシーを更新するたびに、Oracle JDeveloperの埋込みOracle Containers for J2EE（OC4J）のconfigディレクトリ（JDEV_HOME\system\oracle.j2ee.10.1.3.xx.xx\embedded-oc4j\config）内のsystem-jazn-data.xmlファイルが更新されます。同時に、ポリシーがアプリケーションとともにデプロイされるように、これらの変更内容はapp-jazn-data.xmlファイルにも伝播されます。このモデルの結果として、次のガイドラインに準拠する必要があります。
ポリシーはグローバルで、保護されたオブジェクトの名前に基づいています。このため、コンポーネント内でオブジェクトのネーミングが確実に一意になるように、開発者チームはグローバルなネーミング規則を使用する必要があります。grant内に定義されたオブジェクトがすでに存在している場合、そのオブジェクトのポリシーがマージされるため、予期しない結果が発生することがあります。
（たとえば、正規表現やワイルドカードを使用して）system-jazn-data.xmlファイルを手動で変更した場合、CVSにチェックインする前に、これらの更新内容をapp-jazn-data.xmlファイル内に手動でレプリケートする必要があります。app-jazn-data.xmlの詳細は、C.6.1項「app-jazn-data.xml」を参照してください。
system-jazn-data.xmlファイルを常に正確で最新にするためには、各開発者が、ソースとしてCVSからのapp-jazn-data.xmlを、宛先としてJDEV_HOME\system\oracle.j2ee.10.1.3.xx.xx\embedded-oc4j\config内のsystem-jazn-data.xmlを使用して、JAZN移行ツールを実行することをお薦めします。
system-jazn-data.xmlファイルを常に正確で最新にするためには、各開発者が、CVSから最新のアプリケーション・ファイルを取り込むたびに次の手順を実行することをお薦めします。
|
注意: app-jazn-data.xmlはアプリケーション・ナビゲータに表示されないため、変更された日時の判別が難しいことがしばしばあります。このため、CVSから最新のファイルを取り込むたびに変更をsystem-jazn-data.xmlにマージするのが安全なガイドラインです。 |
開発者はこの手順をかなり頻繁に実行する必要があるので、これを処理するための簡単なバッチ・スクリプトを開発すると効果的です。例11-1に、このようなバッチ・スクリプトのサンプルを示します。環境のEMBED_SYS_JAZNパス内のxx.xxを変更する必要がありますので注意してください。
例11-1 system-jazn-data.xmlファイルを更新するためのMS Windowsバッチ・スクリプトのサンプル
@ECHO OFF CLS ECHO ================== Merging Policies ==================== SET JDEV_HOME=C:\jdev SET APP_JAZN=%JDEV_HOME%\jdev\mywork\Application1\.adf\META-INF\app-jazn-data.xml SET EMBED_SYS_JAZN=%JDEV_HOME%\jdev\system\oracle.j2ee.10.1.3.xx.xx\embedded-oc4j\ config\system-jazn-data.xml SET CLASSPATH=%JDEV_HOME%\j2ee\home\jazn.jar;%JDEV_HOME%\BC4J\lib\adfshare.jar ECHO Java Home : %JDEV_HOME% ECHO Source File : %APP_JAZN% ECHO Dest File : %EMBED_SYS_JAZN% ECHO . ECHO Updating Oracle JDeveloper's embedded OC4J system-jazn-data.xml java oracle.security.jazn.tools.JAZNMigrationTool -sr jazn.com -dr jazn.com -st xml -dt xml -sf %APP_JAZN% -df %EMBED_SYS_JAZN% -m all ECHO =========================================================
例11-2に、例11-1のバッチ・スクリプトを実行したときに得られる出力を示します。
例11-2 バッチ・スクリプトからのサンプル出力
================== Merging Policies ==================== Java Home : C:\JDev Source File : C:\JDev\jdev\mywork\Application1\.adf\META-INF\app-jazn-data.xml Dest File : C:\JDev\jdev\system\oracle.j2ee.10.1.3.40.40\embedded-oc4j\config\ system-jazn-data.xml . Updating Oracle JDeveloper's embedded OC4J system-jazn-data.xml =========================================================
