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のオブジェクトはプロジェクトごとに一度だけ作成され、参照および使用するユーザーに関係なく、定義によって同じ名前を持ちます。ただし、データベース接続のような一部のオブジェクトの場合は、同じ接続の詳細にマップされるとしても、論理的には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リポジトリにコミットできるようになります。マージ・ツール・ウィンドウを閉じ、次の競合(存在する場合)に進むことができます。
「送信」ページを使用して変更をコミットします。
最後は、「保留中の変更」ウィンドウの「送信」ページを使用して、自分の変更をソース・コントロールにコミットします。変更済だがコミットしないファイルが存在する場合があります。たとえば、埋込みOC4Jサーバー上で自分のアプリケーションを実行するたびに、自プロジェクトのdata-sources.xml
ファイルまたはjazn-data.xml
ファイル(あるいはその両方)のコンテンツがJDeveloperによってリフレッシュされる場合があります。通常は、毎回これらの変更済バージョンをチェックインする必要はありません。また、ファイルは変更済でも、変更内容を保持しないファイルが存在する場合もあります。そのようなファイルの場合は、アプリケーション・ナビゲータのポップアップ・メニューから「バージョニング」→「変更を元に戻す」を選択します(これはいつでも実行できます)。これにより、該当するファイルは、ソース・コントロール内で最後にチェックインされたバージョンに戻ります。最後に、チェックインするファイルを選択し、ポップアップ・メニューの「コミット」を選択します。
ヒント: 「保留中の変更」ウィンドウのツールバーにある「すべてコミット」ボタンを使用すると、「送信」リストのすべてのファイルがコミットされます。選択したファイルをコミットする場合は、前述の方法を使用してください。 |
CVSリポジトリを誤って破損しないよう、リポジトリの構成ファイルを手動で変更しないでください。CVS構成ファイルを変更する必要がある場合は、CVSROOTをモジュールとしてチェックアウトし、特定の構成ファイルをローカルで変更し、リポジトリにコミットします。
開発者が複数存在する環境では、ADF Business ComponentsパッケージのXMLファイルの使用を無効化すると、マージ競合の原因を1つ除去できます。その場合は、「設定」ダイアログの「ビジネス・コンポーネント: 一般」ページで、「クラス・パスへのパッケージXMLファイルのコピー」オプションの選択を解除します。4.4.7.2項「推奨事項: パッケージXMLファイルの使用の無効化」を参照してください。
JDeveloperのADF Business Componentsプロジェクトでビジネス・コンポーネントの追加または削除を実行すると、JDeveloperはそれをプロジェクト・ファイル(.jpr
)に反映します。新しいパッケージの中に作成(またはリファクタ)によってコンポーネントが格納されると、JDeveloperはそれをビジネス・コンポーネント・プロジェクト・ファイル(.jpx
)に反映します。これらXMLフォーマットのプロジェクト管理ファイルはマージ競合の発生が減るように最適化されていますが、マージ競合はまだ発生する可能性があり、それらのマージ競合は、影響を受ける各ファイルのポップアップ・メニューにあるJDeveloperの「競合の解決」オプションを使用して解決する必要があります。
ADF Business ComponentsのXMLコンポーネント・ディスクリプタ・ファイル、ADF Business Componentsプロジェクトのプロジェクト・ファイル(.jpr
)または対応するビジネス・コンポーネント・プロジェクト・ファイル(.jpx
)でマージ競合が解決した後は、該当するプロジェクトを一度閉じてから再度開き、最新バージョンのコンポーネント定義を使用していることを確認してください。その場合は、該当するプロジェクトをアプリケーション・ナビゲータで選択し、JDeveloperのメイン・メニューから「ファイル」→「閉じる」を選択した後、該当プロジェクトをアプリケーション・ナビゲータで再度展開します。