3 チームでの効率的な作業

この章では、開発者がOracle JDeveloperでファイルを共有する場合のチーム開発環境について説明します。たとえば、ソース(またはバージョン)・コントロール・システム、Subversionに関する情報などがあります。

この章の内容は、次のとおりです。

• 第3.1項「WebCenter Portal開発でのソース・コントロールの使用」

• 第3.2項「Oracleチーム・プロダクティビティ・センターの使用」

• 第3.3項「ソース・コントロールにチェックインするファイルの決定」

• 第3.4項「1回での共通要件の実装」

• 第3.5項「ポートレット・プロデューサに関する考慮事項」

3.1 WebCenter Portal開発でのソース・コントロールの使用

WebCenter Portalのソース・コントロールは、その他の開発環境のソース・コントロールと同様の方法で使用できます。

JDeveloperには、ソース・コントロールのSubversionが含まれます。Oracleは、CVS (Concurrent Versions System)、DimensionsおよびClearCaseなどの他のソース・サポート・システムへの無料の拡張機能も提供します。これらの拡張機能は、JDeveloper内の「ヘルプ」→「更新の確認」メニュー・オプションから直接インストールできます。これが、拡張機能をインストールする推奨方法です。JDeveloperインスタンスからインターネットに接続できない場合は、Oracle Technology Network (OTN)(http://www.oracle.com/technetwork/index.html)から拡張機能をダウンロードします。更新の確認ウィザードで、ダウンロードするローカル・ファイルを指し示します。

注意: 拡張機能にアクセスするにはプロキシ・サーバーを構成する必要がある場合があります。詳細は、Oracle JDeveloperオンライン・ヘルプのプロキシ設定とJDeveloperに関するトピックを参照してください。

JDeveloperを使用したSubVersionおよびその他のソース・コントロール・システムの設定と使用の完全かつ詳細な情報は、Oracle JDeveloperオンライン・ヘルプのチームでの開発に関するトピックを参照してください。

3.2 Oracleチーム・プロダクティビティ・センターの使用

Oracleチーム・プロダクティビティ・センターはアプリケーション・ライフサイクル管理ツールで、このツールを使用すると、ソフトウェア開発チームは、JDeveloperを使用したポータルの開発時に共同作業と効率的な作業が可能になります。これもJDeveloperの無料の拡張機能です。

Oracleチーム・プロダクティビティ・センターは、タスク、バグ、および不具合のリポジトリ(JIRAやBugzillaなど)と、独自の組込みタスク・リポジトリをIDEに統合します。また、JDeveloper内のチャット・インタフェースや、その他のチーム作業に役立つ機能(タスクに対してソース・コントロール・システムにチェックインされたファイルの詳細を記録する機能や、IDEのコンテキストを保存するなどの開発者の生産性支援機能など)を提供します。

Oracleチーム・プロダクティビティ・センターの詳細やダウンロードは、http://www.oracle.com/technetwork/index.htmlのOracle Technology Network (OTN)を参照してください。

3.3 ソース・コントロールにチェックインするファイルの決定

ソース・コントロール・システムを使用する際には、どのファイルをチェックインし、どのアクションがそれらのファイルに作用するかを理解していることが重要になります。一般に、チーム・メンバーが新しいプロジェクトの作成を開始すれば、どのファイルが作成されるかがわかり、何をソース・コントロールにチェックインすればよいかを判断できます。考えられるすべてのファイルとのやり取りをまとめることは困難ですが、この項では一般的なヒントをいくつか提供します。

表3-1に、開発者が一般的にやり取りを行ういくつかのコンポーネントと、これらのコンポーネントおよび関連ファイルの詳細へのリンクを示します。

表3-1 一般的なコンポーネント

コンポーネント	詳細の参照先
ページ	ページ・メタデータ・ファイルの詳細は、『Oracle Application Development Framework Fusion開発者ガイド』のADFメタデータ・ファイルの概要に関する項を参照してください。
ポートレット	ポートレットおよびプロデューサ・メタデータ・ファイルの詳細は、付録A「WebCenter Portalのファイル」を参照してください。第59章「 JSR 286を使用した標準ベースのJavaポートレットの作成」も参照してください。
タスク・フロー	ADFタスク・フローの詳細は、Oracle Application Development Framework Fusion開発者ガイドのADFタスク・フローの概説に関する項を参照してください。
データ・コントロール	データ・コントロールの詳細は、『Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

ソース・コントロールの戦略を計画するときに確認する可能性のあるその他の機能および関連ファイルについては、付録A「WebCenter Portal Files」を参照してください。この付録では、Portal Frameworkファイル、システム・ファイル、JDeveloperファイルなどについてリストし、説明しています。

3.4 1回での共通要件の実装

プロジェクト管理者は、開発者に共通する要件を一度に実装して、そのバージョンを全員が使用できるようにチェックインすることをお薦めします。前もって計画し、管理者がこれらの共通要件を考慮しておくことで、冗長的な作業やエラーを削減できます。

たとえば、2人の開発者が、ポータルの別々のページにOmniPortletを追加する必要があるとします。この場合、プロジェクト管理者がOmniPortletプロデューサを登録していれば、両方の開発者がこのプロデューサを使用できます。このようにしていないと、各開発者が別々にOmniPortletプロデューサを登録するようになり、不要な重複と混乱の原因になります。

別の例として、多数の開発者が、同じコンテンツ・リポジトリのコンテンツを必要としているとします。この場合は、最初に1人が必要な接続を設定してチェックインする必要があります。その後、その他の開発者は同じデータ・コントロールを再利用するだけです。

3.5 ポートレット・プロデューサに関する考慮事項

チーム環境で作業する場合は、プロデューサに関する次の考慮事項に留意してください。

• 第3.5.1項「ポートレット・プロデューサの接続」

• 第3.5.2項「異なるポートレット・プロデューサからのポートレットの結合」

3.5.1 ポートレット・プロデューサの接続

プロジェクトに対してEARファイルを構築する場合、個々のプロジェクトではなくポータル全体に対して接続がロードされます。たとえば、P1およびP2という2つのプロジェクトを持つポータルがあるとします。P1には100個のプロデューサが登録されており、P2にはプロデューサは登録されていません。この場合、どちらかのプロジェクトに対してEARファイルを構築すると、P1のプロデューサ接続の100個全部がconnections.xmlにロードされます。ただし、手動でconnections.xmlを編集することもできますので覚えておいてください。

デプロイ前ツールを実行してターゲットのEARファイルを作成する場合、connections.xml内のすべての接続にアクセスできる必要があります。このため、この例では、P1の100個のポートレット・プロデューサ接続のいずれかがなんらかの理由で使用不可能になると、どちらのプロジェクトのターゲットのEARファイルも生成に失敗します。全体の開発作業をポータルおよびプロジェクト別に分担するときは、この動作を考慮して、慎重に計画する必要があります。

3.5.2 異なるポートレット・プロデューサからのポートレットの結合

場合によっては、複数の開発者でポートレットを構築し、最終的にこれらのポートレットを1つのポートレット・プロデューサの下に結合することが必要になります。この各開発者は、いくつかの潜在的な問題を意識している必要があります。

• ポートレット名とJSPパスは、クラッシュする可能性があります。あるポータルで1つのポートレット・プロデューサ内にポートレットを結合する場合、ポートレット開発者は、ネーミングのクラッシュを回避するために、事前に準備したクラス・パッケージ名およびJSPパスを使用する必要があります。

• ポートレット・ウィザードでJPSポートレットを作成する場合、ポートレット・モードのディレクトリはデフォルトでportletn\html\mode_nameになります。nは、作成するポートレットごとに増分する数になります。ディレクトリ名やファイル名のクラッシュを避けるために、ポートレット開発者は、ポートレット・ウィザードの「コンテンツ・タイプ」ページと「ポートレット・モード」ページでディレクトリ名を変更する必要があります。ポートレット・モードを選択して、対応するフィールドでディレクトリ名が一意になるように変更します。

• ポートレットを1つのポートレット・プロデューサ内に結合するときには、ポートレット・ディスクリプタ・ファイルを手動でマージする必要があります。このとき、次のようにして識別子のクラッシュを回避します。

  • portlet.xmlおよびoracle-portlet.xmlファイル内のJPSポートレット識別子は、portlet1から始まって順に自動生成されます。複数のポートレット・ディスクリプタ・ファイルを手動で1つにマージするとき、他のポートレット識別子とクラッシュするポートレット識別子はすべて変更する必要があります。

  • 同様に、provider.xml内のPDK-Javaポートレット識別子は、1から始まって順に自動生成されます。複数のprovider.xmlファイルを手動でマージするとき、他のポートレット識別子とクラッシュするポートレット識別子はすべて変更する必要があります。

• Webディスクリプタ(web.xml)の変更内容(セキュリティ・ロール情報など)も手動でマージする必要があります。

• PDK-Javaポートレットの場合は、.propertiesファイルも手動でマージする必要があることがあります。

• 多様なポートレットを使用している場合には、他者による上書きや、変更されたファイルがJDeveloperで正しく選択されないなどの理由で、ファイルの一部が適切にチェックインされない場合があります。たとえば、多様なポートレットのあるポータルをデプロイすると、3つのOmniPortletsのうちの2つで次のエラーが表示される可能性があります。

  mdsId
  oracle/adf/portlet/OmniPortlet_1172537210873/ap/Portlet100_0b4156e9_0111_1000_
  8001_82235f273a39.pxml not found
   
  mdsId
  oracle/adf/portlet/OmniPortlet_1172537210873/ap/Portlet100_250498fc_0111_1000_
  8002_a9fe7286a54e.pxml not found
  

  このようなエラー・メッセージが表示された場合は、開発環境のすべての*.pxmlファイルがデプロイ環境にコピーされていることを確認してください。

• ポートレットのカスタマイズが、デプロイ環境で表示されない場合があります。oracle\adf\portlet\<portletInstanceName>.pxmlファイルのコンテンツが適切で、正しい*.pxmlファイルを参照していることを確認してください。