複数のアプリケーションにわたるOracle ADF開発のSubversionによる管理

Oracle JDeveloperのHow toドキュメント
オラクル、 Susan Duncan著
2009年4月

はじめに

Oracle Application Development Framework（Oracle ADF）開発は、さまざまな方法で実施できます。 一部の組織では、多くのプロジェクトで構成される1つのOracle ADFアプリケーションの使用が望まれており、 ほかの組織では、開発を機能分野ごとに分けて複数のアプリケーションに分散することが望まれています。 また、開発環境の管理も、さまざまな方法で実行できます。 決定する必要がある多くの事項の中には、コードを格納してバージョニングする方法、およびチーム間でADFライブラリを共有する方法があります。 これを実現する手法は数多くありますが、もっとも一般的なのはMavenなどのツールを使用することです。Oracle JDeveloperのResource Catalogを使用して共有リソースにアクセスするか、またはソース・コード管理システムによって提供される機能を活用します。

このドキュメントでは後者の手法、とくにSubversion（SVN）を使用してチームと複数のアプリケーションとの間でADFライ ブラリなどの共通コンポーネントのバージョニングおよび共有の管理をおこなう手順を提案します。 このドキュメントでは共有コンポーネントの最適な配置を実現する方法をそのまま説明しているため、MavenまたはResource Catalogの使用については対象外となっていますが、 後日、別のドキュメントで取り上げる予定になっています。

 

Subversionの活用

このドキュメントでは、次のようなチーム開発を実施するための作業手順を提案します。

  • Oracle ADF Business Componentsがビジネス・サービス・レイヤーを提供
  • 開発を機能分野ごとに分けて複数のADF Fusionアプリケーションに分散
  • 複数のアプリケーションの開発を同時に実施
  • Subversionを使用してソース・ファイルをバージョニング
  • 異なるアプリケーション内で開発された共通ADFコンポーネントを、ADFライブラリを使用して共有
  • SVNを使用して、ADFライブラリおよび任意のサード・パーティ製ライブラリを保存し、開発者に配布

この手順は、機能分野ごとに分けられたチームがいくつかの共通コンポーネントを使用して作業をおこなうためのものです。 通常は、1つのアプリケーションを使用して再利用可能なADFビジネス・サービスを開発します。 このアプリケーションは、再利用可能なエンティティ・オブジェクトを保持します。 さらに、アプリケーションは、再利用可能なビュー・オブジェクトも保持できます。 UIの開発は、ADFライブラリを介して共通のビジネス・サービスにアクセスする複数のアプリケーションを使用して、機能分野ごとに分散されます。 また、各UIアプリケーションをADFライブラリとして公開すれば、共通コンポーネント（アンバウンド・タスク・フローなど）を共有できます。

 

アプリケーションの設定

開発は、複数のアプリケーションに分散されます。 このドキュメントでは、アプリケーションのネーミング規則は提案せず汎用の名前を使用するので、名前は必要に応じてカスタマイズする必要があります。

 

共通コンポーネント・アプリケーション

通常、このアプリケーションでは、ライブラリを介して共有されるビジネス・コンポーネント、またはアプリケーション間で共有できるイン フラストラクチャ・コンポーネントを保持します。 コンポーネントには、以下が含まれます。

  • ADFライブラリに配置されるビジネス・コンポーネントを含むプロジェクト
  • プロジェクトに保持されているサード・パーティ製のライブラリ
  • オフライン・データベース・モデル

このアプリケーションに対する書込みアクセスは、共有コンポーネントとライブラリを使用して機能するアプリケーションに限定されます。

この例では、1つのプロジェクト CommonADFModelを含む共有コンポーネン ト・アプリケーション CommonComponentsが示されています。 このアプリケーションは、SVNリポジトリからチェックアウトしたアプリケーションの作業用コピーです。

CommonADFModelプロジェクトには、Oracle ADFのエンティティ・オブジェクトが含まれています。これらのオブジェクトは、異なる開発チーム間でADFライブラリ commonModelEOを 介して共有されます。

ライブラリは、すでにデフォルトのプロジェクト・フォルダに配置されています。

注： この図にあるライブラリを表示するために、プロジェクト・リソースのパスにdeployフォルダが追加されています。

 

チーム開発アプリケーション

各アプリケーションは、開発の1つの機能分野に対応しています。 アプリケーションは、SVNリポジトリにある任意のADFライブラリを直接共有するように設定する必要があります。 開発者は、開発のためにアプリケーションの'作業用コピー'をチェックアウトし、通常の方法で更新してSVNリポジトリにコミットします。

配置されたADFライブラリは、SVNリポジトリから直接共有されます。 これによって、アプリケーションで作業をするすべての開発者が常に正しいバージョンのライブラリを使用することが保証されます。 これは、ライブラリを共有ファイル・システムに保存してResource Paletteからそれにアクセスする方法の代わりに使用される手段です。 Resource Paletteの使用方法は、このドキュメントの対象外です。

commonModelEOライブラリの利用に加えて、各チームの開発アプリケーションは、ほかのチームの開発アプリケーションからの ADFライブラリを提供および利用することがあります。 通常、このような状況になるのは、異なる機能分野の間でバウンド・タスク・フローが共有される場合です。 バウンド・タスク・フローの説明は、このドキュメントの対象外です。

バウンド・タスク・フローとADFライブラリの使用方法については、OTNで入手可能な『 Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

 

マスター・デプロイメント・アプリケーション

このアプリケーションは、すべての共通コンポーネント・アプリケーションとチーム開発アプリケーションを集めて1つのフル開発バージョ ンにまとめます。 通常、フル開発バージョンはそれ自体で機能分野別の開発を可能にするだけでなく、ほかのすべての共有コンポーネントも利用することによって、テストおよび リリースを目的とした完全なアプリケーションを提供します。

 

SVNの設定

リポジトリの構成

SVNにおける開発フォルダ構造の設定には、多くの方法があります。 このドキュメントでは、複数のアプリケーションを使用する場合の1つの方法を提案します。

ルート・ディレクトリ MultiAppExampleには、開発したすべてのアプリ ケーションが格納されます。

各アプリケーションには、独自の trunk、tags、branches構造がありま す。この構造は、開発プロセスのマイルストーンに対応し、適切に分岐しています。

メインの開発はtrunkディレクトリで実施され、tagsディレクトリはマイルストーンとリリースの格納に使用されま す。

この例では、このドキュメントで先ほど紹介したアプリケーション構造がSVNリポジトリの構造に反映されています。

 

タグによるライブラリ共有

Subversionでは、タグ・ディレクトリを使用してマイルストーン（コードの各バージョン）を格納します。 タグ・ディレクトリは、特定のリビジョン（時点）における開発の単純なコピー*です。 タグ・ディレクトリの作成とアクセスの管理は、SVNリポジトリの管理者に任されています。

*SVNでは、ディレクトリのブランチまたはタグを作成することを'コピー'と呼びます。 ただし、これは単にポインタとして使用されているだけで高度な操作ではありません。

この例では、 CommonComponentsAppアプリケーションのtagsディ レクトリの下に CommonComponents_Feb2009_v1ディレクトリがすでに作成されています。

 

 

Versioning Navigatorによるタグの作成

タグを作成するには、タグ・バージョンの作成元になるディレクトリ（通常はアプリケーション・ディレクトリ）を選択しま す。 このディレクトリおよびそのすべてのサブディレクトリにある内容のコピーが作成されます。

ディレクトリのコンテキスト・メニューで、「 Branch/Tag」メニューを選択し ます。

この例では、 trunk/CommonComponentsのヘッド・リビジョン（最 新リビジョン）のコンテンツが、タグ・ディレクトリ tags/CommonComponents_Feb2009_v1に コピーされます。

 

その結果、ディレクトリのコンテンツがタグ・ディレクトリにコピーされました。 このコピーには、ADFライブラリが配置されたディレクトリが含まれています。 ただし、そのディレクトリにあるのは、ほかのアプリケーションと共有するcommonModelEO.jarファイルだけです。

アプリケーションの完全なコピーを作成することにより、任意のリビジョンのライブラリを構成する設計時コンポーネントを、 必要に応じて確実に再作成できます。

 

バージョニングされたディレクトリのファイルURLへのアクセス

SVNプロパティの設定のようなアクションを実行するには、バージョニングされたファイルまたはディレクトリへのアクセス が必要になることがあります。

そのためには、Versioning Navigatorでディレクトリのコンテキスト・メニューから Copy URLまたは Propertiesのいずれかを選択します。

この例では、タグ・ディレクトリCommonComponents_Feb2009_v1にあるdeployディレクトリ のURLがコピーされています。

SVNリポジトリからのプロジェクトにライブラリを追加するには、 svn:externalsプロ パティを使用します。 プロパティの設定とSVNリポジトリへのコミットが完了したあと、アプリケーションのユーザーがSVNリポジトリからの作業用コピーをチェックアウトまた は更新すると、すべてのユーザーはそのライブラリを取得することになります。

共有の設定は、アプリケーション開発のできるだけ早い段階で実施することを推奨します。 アプリケーションの最初のバージョニングが完了すると、利用するライブラリをsvn:externalsプロパティを使用して取得できるようになります。

 

チーム開発アプリケーションによるADFライブラリの共有

開発中にアプリケーション間でADFライブラリまたはそのほかの共有コンポーネントを追加するために、SVNからライブラリに直接アク セスすることを推奨します。 これによって、開発段階で各バージョンをリリースする仕組みを管理できます。 これは、開発を共有コンポーネントと非共有コンポーネントの両方に対して同時に実施する場合はとくに重要となる可能性があります。

SVNリポジトリからのプロジェクトにコードを追加するには、 svn:externalsプロパ ティを使用します。 アプリケーションのプロパティ設定が完了したあとで、アプリケーションのユーザーがSVNリポジトリからの作業用コピーをチェックアウトまたは更新する と、すべてのユーザーはそのライブラリを取得することになります。

共有の設定は、アプリケーション開発のできるだけ早い段階で実施することを推奨します。 アプリケーションの最初のバージョニングが完了すると、利用するライブラリをsvn:externalsプロパティを使用して取得できるようになります。

 

svn:externalsプロパティの設定

最初の手順は、SVNリポジトリ内にあるライブラリが格納されているディレクトリのファイルURLをコピーすることです。 前述した手法を使用します。

Application Navigatorで、共有ライブラリが格納されているプロジェクト・ノードを選択します（この例では TeamApp1Model）。

Versioningメニューで、「 View Subversion Properties」を選択します。

Subversion Propertiesウィンドウで、「 Add Subversion Property」をクリックします。

Resource Fileフィールドで、パスからプロジェクトの.jprファイルを削除して、プロジェクト・ルート・フォルダを残します（この例では TeamApp1Model）。

ドロップダウン・リストから「 svn:externals」を選択します。
注： このドロップダウン・リストには、Application Navigatorで選択したノードに適したsvnプロパティだけが表示されます。 svn:externalsが表示されない場合は、フォルダ（この例ではプロジェクト・ルート・フォルダ）が選択されていない可能性があります。

Value Stringのテキスト・ボックスに、ライブラリを格納する新しいディレクトリを追加します（このディレクトリがまだファイル・システムに存在していない ことを確認することが必要）。 この例では、 shared_commonComponentsを使用しています。

空白文字を残したままで、ライブラリを格納するタグ・フォルダのURLを貼りつけます（このドキュメントのタグに関する項 で説明したように）。

この場合、SVNリポジトリのプロトコルは svn://になります。

「 OK」をクリックします。

この時点で、プロジェクトに対応するSubversion Propertiesウィンドウにプロパティが表示されていることを確認します。

SVN Console - Logを使用して、リポジトリ内にプロパティが設定されていることを確認します。 プロジェクトのResources Fileフィールドのソース・パス（.../Team1App/TeamApp1Model）には、共有ライブラリを格納する新しい shared_commonComponentsディレクトリが作成されることに注意してください。

最後に、Update Working Copyを使用して、共有ライブラリをローカルの作業用コピーにコピーします。

 

共有ライブラリのプロジェクトへのインポート

SVNリポジトリからライブラリのコピーを共有しました。次の手順は、ライブラリを使用するプロジェクトを設定することです。 ADFライブラリを使用する場合は、次の手順を実行する必要があります。 ADFライブラリが別のサード・パーティ製ライブラリの場合は、そのライブラリをプロジェクトLibrariesとClasspathに追加するだけで十 分です（これを実行するにはProject Propertiesダイアログを使用しますが、その説明については、このドキュメントの対象外です）。

 

Business Components用のプロジェクトの設定

Oracle ADF Business Components用のプロジェクトがまだ設定されていない場合は、次のいずれかを実行する必要があります。

  • Business Componentsを対象にしたテクノロジーを含む新しいプロジェクトを作成
  • 既存のプロジェクトのProject Propertiesダイアログに移動して、Business Components用のプロジェクトを初期化

 

Business Componentsの共有ADFライブラリのインポート

プロジェクトのProject Propertiesダイアログを開いて、ライブラリのコンポーネントを格納します。 Business Componentsの下にある「 Imports」を選択して、 svn:externalsプ ロパティで指定したファイル・システムの場所から commonModelEO.jarを追加します。 これによって、プロジェクトLibrariesにjarファイルを自動的に追加するオプションが提供されます（これは、Librariesと Classpathのプロジェクト・プロパティを調べることで確認できます）。

さらに、Project Source Paths - Resourcesに移動してリソースのパスにディレクトリを追加し、ナビゲータでオブジェクトの読取り専用バージョンを確認します。

 

ADFライブラリの最新リビジョンへの移行

開発中は、任意の共有ADFライブラリの新バージョンが繰り返し配置されます。 この新バージョンをほかのユーザーが取得できるようにする場合、またはそれが何らかのマイルストーン・リリースである場合は、アプリケーションに永続的か つ簡単にアクセスできるようにそのアプリケーションをタグ付けします。

この操作には、次の3つの段階があります。

  1. ADFライブラリのタグ付けされた新しいリビジョンを作成
  2. タグ付けされた新しいリビジョンをポイントするように、各アプリケーションのsvn:externalsプロパティを更新
  3. チェックアウトしたすべての作業用コピーを更新してリフレッシュし、インポートしたADFライブラリをリロード

注： プロジェクトまたはSVNに格納されているサード・パーティ製のライブラリにも、同じ手順が適用されます。

 

ADFライブラリの最新リビジョンに対する新しいタグの作成

Versioning Navigatorを使用して、 CommonComponentsAppの コンテキスト・メニューで「 Branch/Tag」を選択します。

 

通常は、ヘッド・リビジョン（最新リビジョン）を使用してタグを作成します。

Fromフィールドに、アプリケーション・リポジトリのパスが表示されます。この例で は、 .../trunk/CommonComponentsになっています。

Toフィールドで、アプリケーションのtagsディレクトリを参照して、新しいタグ・ ディレクトリを書き込みます。

この例では、 .../tags/CommonComponents_Mar_09_v2を 使用しています。

「 OK」をクリックして、タグを作成します。

 

 

ADFライブラリのタグ付けされた最新バージョンをポイントするようにチーム開発アプリケーションを設定

この操作では、以前に設定したsvn:externalsプロパティを変更します。 これは、特定のマイルストーンでユーザーの作業用コピーがマージされて競合が解決している場合に効果的で、新旧のライブラリ・コードの間で競合が発生する 可能性が減少します。 そのあと、更新の対象になっているチーム開発アプリケーションの作業用コピーをチェックアウトします。

Application Navigatorで、共有ライブラリを共有するプロジェクト・ノードを選択します。

Versioningメニューを使用して、Subversion Property Viewerを開きます。

「 svn:externals」プロパティを選択して「 Edit」 を選択し、Edit Subversion Propertyダイアログを開きます。

Value Stringのテキスト・ボックスの内容を、ライブラリのタグ付けされた新しいライブラリ・ディレクトリをポイントするように変更します（前述のように、 リポジトリ上でCopy URLコマンドを使用）。

この例では、../ CommonComponents_Mar_09_v2/.......に なります。

「 OK」をクリックして、編集したプロパティを保存します。

注： この操作では既存のsvn:externalsプロパティを編集するので、同じファイル・システム・ディレクトリを使用できます（前出の項で説明したよう に、svn:externalsを初めて設定する場合は、このファイル・システム・ディレクトリが存在していないことを確認する必要があります）。

作業用コピーを更新して最新のライブラリにアクセスします。プロジェクト・コンテンツをリフレッシュする際には、次の注意 事項を確認してください。

 

チェックアウトした作業用コピーの更新

各ユーザーは、SVNリポジトリからの作業用コピーを更新することで、リポジトリから最新のADFライブラリをダウンロードして取得す る必要があります。

さらに、更新されたADFライブラリのプロジェクトへのリロードを確実におこなうために、Application Navigatorでプロジェクトをいったん閉じてから再び開くか、またはOracle JDeveloperをいったん終了してから再び起動します。