| Oracle Application Development Framework開発者ガイド 10g（10.1.3.0） B40012-02 |
|
 戻る |
 次へ |
SRDemoアプリケーションに使用されるソース制御システムはCVSでした。この章は、ADFプロジェクトでCVSを使用する際のアドバイスとJDeveloperでCVSを使用する際の一般的なアドバイスで構成されています。
この章の内容は次のとおりです。
この項は、SRDemoアプリケーションなどのADFプロジェクトでCVSを使用する際のアドバイスです。
CVSクライアントでは、CVSへの作業のインポートやCVSコントロールからの作業のチェックアウトを行えます。CVSクライアントはスタンドアロン・プログラムとして、またはJDeveloperのようにIDEに組み込んで使用できます。SRDemoアプリケーションは、JDeveloperの内部CVSクライアントを使用して作成されました。
JDeveloperでCVSを使用するように設定します。「拡張機能」プリファレンス・ページ（「ツール」→「設定」→「拡張機能」→「バージョニング・サポートn.n」→「構成」）でCVS n.nのサポートが選択され、「バージョニング」プリファレンス・ページ（「ツール」→「設定」→「バージョニング」）で「CVS」がドロップダウン・リストから選択されていることを確認してください。
CVSを使用するための設定は、「ツール」→「設定」→「拡張機能」→「バージョニング」→「CVS」とそのサブページを選択して設定します。
SRDemoアプリケーションは、CVSのデフォルト設定を使用して作成されましたが、リモート・サーバーと接続速度が遅い場合などは特に、タイムアウトを10分に変更した方がよい場合があります（「一般」サブページの「操作タイムアウト」）。
JDeveloperは、CVSバージョン管理システムと連携して、同期された複数ファイル・コンポーネント内で各ファイルを維持します。たとえば、明示的にチェックアウトされたファイルに依存するファイルは、すべて自動的にチェックアウトされます。ただし、Oracle ADFベースのJSPページを操作する場合、様々な関連オブジェクト間の依存性に注意する必要があります。
たとえば、SomeName.jspなどのJSPページをコミットする際に、JDeveloperで加えた変更により関連するSomeNamePageDef.xmlファイルにも変更が発生している場合、そのファイルも保留中の変更ウィンドウの「送信」ページに表示されます。一方で、SomeName.jspがデータ・バインド・コントロールをドロップして作成された新規JSPページの場合、関連するSomeNamePageDef.xmlファイルが保留中の変更ウィンドウの「候補」ページに表示され、DataBindings.cpxファイルが「送信」ページに変更済ファイルとして表示されます。これらの関係を理解することで、ソース・コントロール・サーバーのプロジェクトを更新する他の開発者が一貫性のある関連ファイルのセットを受信できるようにするには、どのファイルを同じCVSトランザクションの一部としてまとめてコミットすればよいかを適切に判断できるようになります。
JDeveloperとADFのほとんどのオブジェクトは、プロジェクトごとに1回のみ作成され、参照および使用するユーザーとは関係なく、定義に従って同じ名前を持ちます。ただし、データベース接続などの一部のオブジェクトは、理論上独自のJDeveloper環境における各チーム・メンバーの作成に任される可能性があります。これは、それらの接続が同じ接続の詳細にマップされる場合でも同様です。名前が異なると、data-sources.xmlファイルで不必要な差異が発生するため、バージョン管理されたADFで作業する場合、共通の接続定義に対して異なる名前を指定することは避けてください。チーム・メンバーは、前もって大/小文字の区別のある共通の接続名に同意したうえで、その名前をチーム・メンバー全員で使用する必要があります。
一般的に、作業内容は、テストを実行して正常に稼働することを確かめてからコミットする必要があります。コンポーネントは、変更のテストもチェックインも行わないで使用する時間が長くなればなるほど、他の開発者によって変更されている確率が高くなります。その結果、マージ競合が発生し、その解決が必要になります。
なんらかの名前変更操作またはリファクタ操作を実行する場合、アクティブなCVS接続は必ずCVSナビゲータで開いておいてください。これにより、ソース・コントロール・システムで適切なファイルの削除や追加が発生して作業が自動的に処理されます。CVS接続のコンテキスト内でこれらの変更を実行しない場合、次回ソース・コントロールに接続したときに、名前を変更したファイルが意図せず新規ファイルとして表示される可能性があります。
（リファクタなどにより）ファイルの名前を変更する場合は、名前を変更した後できるだけ速やかに、該当するファイルをコミットしてください。JDeveloperからのファイル名の変更には、CVSの削除操作と追加操作が必要です。追加されたファイルを他の開発者も使用できるようにするには、そのファイルをコミットする必要があるからです。ただし、この場合もコミット前に変更をテストする必要があります。通常は、ファイルのリファクタを実行し、ユニット・テストを再実行した後、該当するファイルをコミットします。
新機能の開発時に、他のチーム・メンバーがテスト対象の作業ユニットを完了するためにファイルの作業を行う必要がある場合は、ファイルのコミット前にユニット・テストを実行するという通常の規則を使用しないこともあります。この場合、他のチーム・メンバーがCVSリポジトリからファイルを取得できるように、テスト前にファイルをコミットする必要があります。
作業をCVSにコミットするときは、常に行った変更を説明するコメントを追加してください。コメントは、「CVSにコミット」ダイアログの「コメント」ボックス（「バージョニング」→「コミット」）に入力します。
CVSリポジトリから新しいディレクトリに定期的にクリーン・チェックアウトを実行するようにしてください（「バージョニング」→「モジュールのチェックアウト」を使用）。作業内容のコピーをリポジトリから更新するだけでは（「バージョニング」→「更新」を使用）、不完全なコミットなどの問題が隠れてしまうことがあります。
JDeveloperに組み込まれているApache Antを使用して、完全なソースのチェックアウトとビルドを自動的に実行するようなスクリプトを作成することもできます。ビルドが正常に完了した場合、システムの正常稼働に必要なすべての変更をすべてのユーザーがコミットしていることを確認できます。そうでない場合は、ビルドが中止され、問題点が報告されます。Apache Antを使用してビルド・スクリプトを作成する方法の詳細は、JDeveloperのオンライン・ヘルプに含まれるJDeveloperでのAnt統合の概要に関するトピックを参照してください。
ナビゲーション・ルールをfaces-config.xmlファイルに手動で追加する場合（XMLビューまたは「概要」画面を使用）、faces-config.xmlファイルをチェックインする前に、faces-configのビジュアル・ダイアグラム・ビューに切り替える必要があります。これで、ダイアグラム・ファイル（faces-config.oxd_faces）によってメタデータの変更が登録され、ルールの変更が強制的に反映されます。また、faces-config.oxd_facesファイルがコミット対象としてマークされ、2つのファイルが必ず同期するようになります。
この操作を省くと、ダイアグラム・ファイルがXMLメタデータと矛盾し、エラーが発生します。この問題が発生した場合は、ダイアグラム・ファイルを手動で削除し、次にファイルを開くときにJDeveloperで再作成してください。このファイルは、userinterface/viewcontrollerプロジェクトにある\model\public_html\WEB-INF\faces-config.oxd_facesです。
この項は、JDeveloperでCVSを使用する際の一般的なアドバイスです。
複数のプロジェクト間で開発作業を分割してください。
可能な場合は、Apache Antビルド・スクリプトの一部としてコード・フォーマッタを使用することを検討してください。JDeveloperのコード・フォーマッタは、「設定」ダイアログの「コード・スタイル」ページ（「ツール」→「設定」→「コード・スタイル」）で使用できます。コード・フォーマッタを使用すると、すべてのチーム・メンバーがインポートできる標準のフォーマットを作成およびエクスポートできるため、同じ組込みのコード・フォーマット規則を共有できます。
CVSにチェックインする前とCVSを更新する前にコードをビルドします。
連続的な統合ツールを実行するようにしてください。ツールは、だれかがCVSリポジトリに変更をコミットするたびにプロジェクト全体を再ビルドし、開発者がコミットしたコードによってビルドが失敗した場合は、コードの修復を求める通知を送信する必要があります。連続的な統合ツールを実行すると、CVSリポジトリ内のコードの品質が向上し、開発者が頻繁に更新を行うようになるため、更新の量と競合の数が減少します。連続的な統合ツールの例は、Apache Gump（http://gump.apache.org/）です。
モジュールをインポートする前に、バイナリ・ファイル・タイプをバイナリとして（テキストではなく）インポートするようにCVSリポジトリを構成して、ファイルが破損するのを防いでください。
この項では、CVSコントロール下でファイルを使用する開発者のためのアドバイスを示します。
ファイルの編集を始める前に、常に更新（「バージョニング」→「更新」）またはモジュールのチェックアウト（「バージョニング」→「モジュールのチェックアウト」）を実行して、最新のバージョンで作業してください。
「バージョニング」→「コミット」メニュー・オプションを使用すると一度に1つずつファイルをコミットできますが、作業のコミットには保留中の変更ウィンドウを使用することをお薦めします。このウィンドウを表示するには、JDeveloperのメイン・メニューから「バージョニング」→「保留中の変更」を選択します。チームで作業する場合は、自分が作業していたファイルをコミットする前に、通常は次の順序で保留中の変更ウィンドウを使用します。
「送信」ページを使用してソース・コントロールに新規ファイルを追加します。
最初に、「送信」ページを使用して、現在のワークスペースで作成したすべての新規ファイルを確認します。可能なかぎり最新のリストとなるように、ページ・ツールバーの「リフレッシュ」アイコンをクリックします。ソース・コントロールに追加する新規ファイルを決定し、それらをすべて選択します。次に、ポップアップ・メニューの「追加」オプションを使用して、選択したファイルをソース・コントロールに追加します。コンポーネントは、変更のテストもチェックインも行わないで使用する時間が長くなればなるほど、他の開発者によって変更されている確率が高くなります。その結果、マージ競合が発生し、その解決が必要になります。
|
ヒント: WEB-INF\tempディレクトリはコミットしないでください。これは、実行時に必要に応じてADF Facesが1回だけ生成するキャッシュ・イメージを含むディレクトリであるためです。 |
「受信」ページを使用して他のチーム・メンバーからのワークスペース・ファイルを更新します。
次に、「受信」パネルを使用して、チーム内の他の開発者が加えた変更が、自分がチェックインする予定の作業に影響を与える可能性があるかどうかを確認します。他のチーム・メンバーが、自分のプロジェクトのコピー内にはまだ存在していない新規ディレクトリにファイルを作成した場合は、ワークスペースのポップアップ・メニューまたは個々のプロジェクトの「プロジェクト・フォルダの更新」オプションを使用して、ローカルの作業領域にそれらの新規ディレクトリを反映します。この手順でも、受信ファイルの最新のリストを確認できるように、「リフレッシュ」ボタンをクリックする必要があります。チーム・メンバーの変更ファイルが自分の作業に無関係の場合でも、テスト用として有益であれば、各ファイルのコピーを更新できます。チーム・メンバーの変更ファイルが自分の変更したファイルと同じである場合、受信ステータスに「マージで競合します」と表示されます。CVSサーバーにチェックインする前に、ファイルを更新してマージ競合に対処する必要があります。
必要に応じてマージ競合を解決します。
マージ競合が発生する更新が実行されると、アプリケーション・ナビゲータの各競合ファイルの横に感嘆符（!）が表示されます。また、保留中の変更ウィンドウの「送信」ページで、送信ステータスに「競合」と表示されます。競合は、JDeveloperの組込みマージ・ツールを使用して解決できます。ファイルを右クリックし、ポップアップ・メニューの「競合の解決」を選択します。3つのバージョンのファイルが表示されます（左側にはCVSリポジトリのバージョン、右側には現在のローカル・バージョン、中央にはマージの結果を示す編集可能バージョンが表示されます）。3つのパネル間のマージンの記号は、各競合を解決するための推奨アクションを示します。
マージンの適切なアイコンを選択してポップアップ・メニューを使用すると、左側または右側のファイルから隣接する差異の下に変更を挿入できます。
ツールチップに、各競合に関する推奨アクションが表示されます。推奨されるアクションを受け入れることも、テキストを直接編集することもできます。マージを完了するには、マージ・ウィンドウのツールバーにある「保存」ボタンを使用して、追加した変更を保存する必要があります。このボタンが無効の場合は、状況に応じてポップアップ・メニューの「解決済としてマーク」または「解決済としてすべてマーク」オプションを使用する必要があります。マージしたバージョンのファイルを保存すると、マージ・ツール・ウィンドウは空白になり、ナビゲータ・アイコンから競合記号が削除されます。これで、CVSリポジトリにマージしたファイルをコミットできます。マージ・ツール・ウィンドウを閉じて、（存在する場合は）次の競合の解決に進みます。
「送信」ページを使用して変更をコミットします。
最後に、保留中の変更ウィンドウの「送信」ページを使用して、ソース・コントロールに変更をコミットします。ただし、変更されていてもコミットを希望しないファイルも存在します。たとえば、JDeveloperでは、埋込みOC4Jサーバーでアプリケーションを実行するたびに、プロジェクトのdata-sources.xmlまたはjazn-data.xmlファイル（あるいはその両方）の内容がリフレッシュされる可能性があります。通常は、毎回これらの変更済バージョンをチェックインする必要はありません。また、変更されていてもその変更の保存を希望しないファイルも存在します。このようなファイルについては、任意の時点でアプリケーション・ナビゲータのポップアップ・メニューから「バージョニング」→「変更を元に戻す」を選択できます。これにより、該当するファイルは、ソース・コントロール内で最後にチェックインされたバージョンに戻ります。最終的にチェックインするファイルを選択したら、ポップアップ・メニューの「コミット」を選択します。
|
ヒント: 保留中の変更ウィンドウのツールバーにある「すべてコミット」ボタンを使用すると、「送信」リストのすべてのファイルがコミットされます。選択したファイルをコミットする場合は、前述の方法を使用してください。 |
