Oracle® Fusion Middleware

継続的インテグレーションによるアプリケーションの開発

12c (12.1.2)

E48004-02(原本部品番号:E26997-02)

2014年2月

開発してからFusion Middlewareランタイム環境にデプロイするアプリケーションの自動化と継続的インテグレーションをビルドする方法について説明します。継続的インテグレーションについて説明するために、Subversion、Maven、Archiva、HudsonおよびOracle Mavenプラグインを使用します。

Oracle Fusion Middleware継続的インテグレーションによるアプリケーションの開発, 12c (12.1.2)

E48004-02

Copyright © 2013, 2014,  Oracle and/or its affiliates. All rights reserved.

原本著者: Helen Grembowicz

原本協力著者: Wortimla RS、Sreetama Ghosh

原本協力者: Mark Nelson、Leon Franzen

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 継続的インテグレーションの概要

- 1.1 Oracle Fusion Middlewareの継続的インテグレーションの概要

- 1.2 Subversionを使用したバージョン・コントロール

- 1.3 Mavenを使用したビルド自動化および依存性管理

- 1.4 Archivaを使用したリポジトリ管理

- 1.5 Hudsonを使用した継続的インテグレーション

- 1.6 まとめ

2 継続的インテグレーションのロードマップ

- 2.1 ロードマップ

- 2.2 継続的インテグレーション環境参照の概要

- 2.3 共有ディスク・レイアウト

3 バージョン・コントロールのためのSubversionのインストールおよび構成

- 3.1 Subversionのダウンロード

- 3.2 Subversionのインストール

- 3.3 サービスとしてのSubversionサーバーの構成

- 3.4 リポジトリの設定

- 3.4.1 リポジトリの作成

- 3.4.2 Subversionのレイアウト

- 3.4.3 既存プロジェクトのインポート

- 3.5 SVNワークフローの理解

- 3.6 タグ付けと分岐に関する考慮事項

- 3.7 Subversionクライアント

- 3.7.1 WebSVN

- 3.7.2 TortoiseSVN

- 3.8 詳細情報

4 Archiva Mavenリポジトリ・マネージャのインストールおよび構成

- 4.1 Archivaの概要

- 4.2 Archivaのダウンロード

- 4.3 Archivaのインストール

- 4.4 Archivaの構成

- 4.4.1 サーバーの構成

- 4.4.2 サーバーの起動

- 4.4.3 管理者ユーザーの作成

- 4.4.4 内部リポジトリおよびスナップショット・リポジトリ

- 4.4.5 プロキシ・リポジトリ

- 4.4.6 ミラー・リポジトリの構成

- 4.4.7 開発、本番、品質保証およびテストのリポジトリの作成

- 4.4.8 デプロイメント可能ユーザーの作成

- 4.5 詳細情報

- 4.6 Mavenリポジトリ・マネージャ管理

- 4.6.1 スナップショット・クリーンアップ

- 4.6.1.1 保存オプション

- 4.6.1.2 リリース済スナップショットの削除

- 4.6.2 高度なユーザー管理

- 4.6.3 Archivaのバックアップ

- 4.6.4 Archivaのフェイルオーバー

5 ビルド自動化と依存性管理のためのMavenのインストールおよび構成

- 5.1 Maven配布の設定

- 5.2 Maven設定のカスタマイズ

- 5.3 Mavenリポジトリ・マネージャへの移入

- 5.3.1 Maven同期プラグインの概要

- 5.3.2 Oracle Maven同期プラグインのインストール

- 5.3.3 Oracle Maven同期プラグインの実行

- 5.3.4 アーティファクトの置換に関する予備知識

- 5.3.5 Mavenリポジトリへの移入

- 5.3.5.1 ローカル・リポジトリへの移入

- 5.3.5.2 リモート・リポジトリへの移入

- 5.3.6 pushゴールの実行

- 5.3.7 パッチ適用の予備知識

- 5.3.7.1 パッチ適用に対するOracleのアプローチ

- 5.3.7.2 環境ごとに1つのMavenリポジトリを保持

- 5.3.7.3 パッチ適用後のOracle Maven同期プラグインのpushゴールの実行

- 5.3.8 原型カタログに関する考慮事項

- 5.3.9 settings.xmlの例

- 5.3.10 単一アーティファクトのデプロイ

6 継続的インテグレーションのためのHudsonのインストールおよび構成

- 6.1 Hudsonをインストールおよび構成するための前提条件

- 6.2 Hudsonのダウンロード

- 6.3 Hudsonのインストール

- 6.3.1 LinuxへのHudsonのインストール

- 6.3.2 WindowsへのHudsonのインストール

- 6.4 HTTPポートの構成

- 6.5 Hudsonの開始

- 6.6 起動後のMavenの構成

- 6.6.1 最初の起動時

- 6.6.2 JDKの構成

- 6.6.3 Mavenホームの指定

- 6.6.4 Hudsonで使用するためのMavenの設定

- 6.6.5 Hudsonプラグインのインストール

- 6.6.6 リポジトリの統合

- 6.6.7 Subversionの監視

- 6.7 追加情報

7 Mavenのバージョン番号の理解

- 7.1 バージョン番号がMavenで機能する仕組み

- 7.2 SNAPSHOT修飾子

- 7.3 バージョン範囲参照

- 7.4 Oracle提供アーティファクトのMavenバージョン番号の理解

- 7.4.1 Maven座標のバージョン番号

- 7.4.2 依存性でのバージョン番号範囲

8 Maven POM継承を使用したビルド・プロセスのカスタマイズ

9 Mavenを使用したWebLogic ServerのJava EEプロジェクトのビルド

- 9.1 Mavenを使用したJava EEプロジェクトのビルドの概要

- 9.2 Basic WebApp Maven原型の使用

- 9.2.1 環境にあわせたプロジェクト・オブジェクト・モデル・ファイルのカスタマイズ

- 9.2.2 プロジェクトのコンパイル

- 9.2.3 プロジェクトのパッケージ化

- 9.2.4 Mavenを使用したWebLogic Serverへのプロジェクトのデプロイ

- 9.2.5 様々なオプションを使用したWebLogic Serverへのプロジェクトのデプロイ

- 9.2.6 Basic WebAppプロジェクトのテスト

- 9.3 Basic WebApp with EJB Maven原型の使用

- 9.4 Basic WebService Maven原型の使用

- 9.5 Basic MDB Maven原型の使用

10 Mavenを使用したOracle Coherenceプロジェクトのビルド

- 10.1 Mavenを使用したOracle Coherenceプロジェクトのビルドの概要

- 10.2 Maven原型からのプロジェクトの作成

- 10.3 Mavenを使用したプロジェクトのビルド

- 10.4 Mavenを使用したWebLogic Server Coherence Containerへのプロジェクトのデプロイ

- 10.5 さらに詳細な例のビルド

11 Mavenを使用した実際のアプリケーションのビルド

- 11.1 例の概要

- 11.2 複数モジュールのMavenプロジェクト

- 11.3 Mavenプロジェクトのビルドの開始

- 11.4 GARプロジェクトの作成

- 11.4.1 POMファイル

- 11.4.2 Coherenceの構成ファイルの作成または変更

- 11.4.3 ポータブル・オブジェクトの作成

- 11.4.4 キャッシュにアクセスするためのラッパー・クラスの作成

- 11.5 WARプロジェクトの作成

- 11.5.1 POMファイルの作成または変更

- 11.5.2 デプロイメント・ディスクリプタの作成

- 11.5.3 サーブレットの作成

- 11.6 EARプロジェクトの作成

- 11.6.1 POMファイル

- 11.6.2 デプロイメント・ディスクリプタ

- 11.7 最上位POMの作成

- 11.8 Mavenを使用したアプリケーションのビルド

12 ビルド自動化から継続的インテグレーションへ

- 12.1 依存性管理

- 12.1.1 SNAPSHOTの使用

- 12.1.2 依存の推移性

- 12.1.3 依存性のスコープ

- 12.1.4 複数モジュールのサポート

- 12.2 継続的インテグレーション・デプロイメントをサポートするMaven構成

- 12.2.1 配布管理

- 12.2.2 スナップショット・リポジトリの設定

- 12.3 Hudsonを使用したビルドの自動化

- 12.3.1 Hudsonジョブを作成してMavenプロジェクトをビルドする方法

- 12.3.2 Hudsonビルドのトリガー

- 12.3.2.1 手動によるビルドのトリガー

- 12.3.2.2 Subversionリポジトリによるトリガー

- 12.3.2.3 スケジュール・ベースのトリガー

- 12.3.2.4 Hudsonの依存性変更によるトリガー

- 12.3.2.5 Maven SNAPSHOT変更

- 12.3.3 Hudsonを使用した複数モジュールのMavenビルドの管理

- 12.4 ビルドの監視

- 12.4.1 トリガーされたビルドのフォロー・アップ

はじめに

このマニュアルでは、開発してからFusion Middlewareランタイム環境にデプロイするアプリケーションのビルド自動化と継続的インテグレーションについて説明します。ユーザーがアプリケーションのビルドとテストを自動化し、Fusion Middlewareで継続的インテグレーション手法を簡単に採用できるようにする、Fusion Middleware 12cの機能について説明します。

対象読者

このマニュアルは、Fusion Middlewareランタイム環境にデプロイされるアプリケーションのビルドを担当しており、Fusion Middlewareのコンテキストでビルド・プロセスを自動化したり、継続的インテグレーション手法を採用することを希望している開発者およびビルド・マネージャを対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、Oracle Other Product One Release 7.0のドキュメント・セットまたはOracle Other Product Two Release 6.1のドキュメント・セット内の次のドキュメントを参照してください。

- Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 継続的インテグレーションの概要

この章では、継続的インテグレーションの主要な概念について説明し、Oracle Fusion Middlewareのコンテキスト内での継続的インテグレーション環境の作成に使用できる一連のツールについて説明します。

この章の構成は、次のとおりです。

- 1.1項「Oracle Fusion Middlewareの継続的インテグレーションの概要」

- 1.2項「Subversionを使用したバージョン・コントロール」

- 1.3項「Mavenを使用したビルド自動化および依存性管理」

- 1.4項「Archivaを使用したリポジトリ管理」

- 1.5項「Hudsonを使用した継続的インテグレーション」

- 1.6項「まとめ」

1.1 Oracle Fusion Middlewareの継続的インテグレーションの概要

企業がそのビジネス・ニーズをサポートするためのアプリケーションを開発する場合、通常は開発者のチームを採用しますが、開発者は多くの場合小さなチームで共同で作業し、各チームがアプリケーションの一部をビルドします。次に、これらの部分がアセンブルされてアプリケーション全体が作成されます。

現代の多くのアプリケーションは、サービス指向アーキテクチャ(SOA)に基づいています。これは、開発者がビジネス・アプリケーションのニーズを満たすために様々な方法でアセンブルできるサービス(ビジネス機能の小さな部分)をビルドすることを意味します。SOAの今日の人気をもたらしたSOAの機能の一部を次に示します。

- 変更の影響を軽減する、アプリケーションのコンポーネントの緩やかな結合

- 情報技術開発の長年の目標である、サービスの再利用

- ビジネス・ニーズの変更に応じてアプリケーションの動作を簡単に変更できる柔軟性と俊敏性

この新しいパラダイムでは、多数の開発組織が、古いウォーターフォールスタイル手法を置き換える反復開発手法も採用しています。俊敏で反復的な開発手法では、従来のウォーターフォール・アプローチよりも頻繁に機能の小さな増分を提供することに焦点を当てています。新しいアプローチの支持者は、エラーがすぐに見つかるためエラーによる影響が一般に少ないこと、ビジネス要件が常時かつ急速に変化する今日の環境にこのアプローチが特に適していることを主張しています。

これらの手法の多くには、継続的インテグレーションの採用という特徴もあります。組織はソフトウェアのビルドとテストの自動化に強い関心を持っていますが、継続的インテグレーションは、これを実現するのに役立ちます。

継続的インテグレーションは、小規模かつ頻繁な品質管理を行うことにより、品質の向上およびソフトウェア提供時間の短縮を試みるソフトウェア・エンジニアリング・プラクティスです。次の主要なプラクティスで特徴付けられます。

- バージョン・コントロール・システムを使用して、変更を追跡します。

- すべての開発者が、主なコード行、ヘッドおよびトランクに毎日コミットします。

- 製品は、すべてのコミット操作でビルドされます。

- ビルドは自動化され高速である必要があります。

- 本番に類似した環境に自動的にデプロイされる必要があります。

- 自動化されたテストが有効になっている必要があります。

- すべてのビルドの結果が公開され、ビルドが中断されたかどうかをすべての人が確認できるようにします。

- 開発者、テスターおよびその他のステークホルダーが成果物を簡単に使用できます。

Oracle Fusion Middleware 12cでは、Oracle Fusion Middlewareプラットフォームでアプリケーションを開発するための継続的インテグレーション手法を採用する企業へのサポートを提供しています。具体的には、次のことを提供しています。

- 開発ツールOracle JDeveloperでの一般的なバージョン・コントロール・システムとの統合

- ビルドをスクリプト化および自動化できるように、ビルドおよびプロジェクト管理システムであるMavenを使用してコマンドラインからプロジェクトをビルドする機能

- Maven原型から新規プロジェクトを作成する機能

- Mavenリポジトリから必要な依存性をダウンロードする機能

- 様々な環境(テスト、QA、SIT、本番など)を対象としたビルドを実行できるように、プロジェクトをパラメータ化する機能

- プロジェクトのテストをMavenビルド・ライフ・サイクルに含める機能

- 既存のローカルOracleホーム・ソフトウェア・インストール・ディレクトリからOracle提供の依存性をMavenリポジトリに移入する機能

- Hudsonなどの継続的インテグレーション・サーバーの管理下でMavenビルドを実行する機能

- Oracle Fusion Middlewareで使用するための、ビルドまたは継続的インテグレーション環境あるいはその両方の設定に関する包括的ドキュメント

バージョン・コントロール、継続的インテグレーション、および企業がこの種の環境で通常使用するその他のコンポーネントには選択肢があります。これらのコンポーネントの多くは無料のオープン・ソースであり、その他に市販の製品もあります。このガイドでは、次の一連のコンポーネントに基づく参照環境を示します。

- バージョン・コントロール用のApache Subversion

- ビルドまたはプロジェクト管理用のApache Maven

- Mavenリポジトリ・マネージャとしてのApache Archiva

- 継続的インテグレーション・サーバーとしてのApache Hudson

使用可能な選択肢はこれらに限定されないことに注意してください。たとえば、異なるバージョン・コントロール・システムや異なる継続的インテグレーション・サーバーを使用できます。一般的な選択肢のほとんどでは、それほど苦労せずにこのガイドの例を適応させることができます。

1.2 Subversionを使用したバージョン・コントロール

Subversionは、よく使用されているバージョン・コントロール・システムです。元々は、今日でも依然として広く使用されているConcurrent Versioning System (CVS)の論理的継承として作成されました。Subversionは、次の理由により、このガイドの例でバージョン・コントロール・システムとして使用されています。

- Oracle Fusion Middlewareプラットフォーム用アプリケーションのビルドに最もよく使用されている開発ツールであるOracle JDeveloper、およびその他の一般的な開発ツールと緊密に統合されています。

- 仮想プライベート・ネットワークやHTTPプロキシなど、様々なネットワーク環境で正常に動作します。このため、企業、およびそのパートナやサプライヤがよく遭遇するネットワーク環境に十分適合しています。

- 証明書を使用する厳密認証など、様々な認証オプションをサポートしています。

- Oracle SOA Suiteを使用するプロジェクトの場合、開発者が単一のチェックインまたはコミット操作の一部として複数のファイルを更新できるようにするアトミック・コミットを提供します。

標準的なSubversion環境は、ソース・コード・アーティファクトを格納する1つ以上のSubversionリポジトリで構成されています。これらには、(統合開発環境に含まれているか、またはスタンドアロン・クライアントとしての)Subversionクライアントを使用する開発者がアクセスします。開発者は、アーティファクトをリポジトリにコピーしたり、リポジトリからコピーできます。開発者がアーティファクトを変更すると、新しいバージョンのアーティファクトがリポジトリに作成されます。開発者は、アーティファクトのバージョンを表示および比較して、変更内容や変更者を確認できます。

1.3 Mavenを使用したビルド自動化および依存性管理

Mavenは、プロジェクト管理およびビルド管理システムです。Mavenでは、次の点に関するプロジェクト管理を提供します。

- 命名およびバージョン採番方法

- 依存性

- ソース・コードの格納場所

- ビルドの格納場所

- プロジェクト・タイプのテンプレート

- リリース・プロセス

Mavenでは、次の点に関するビルド管理を提供します。

- ビルドの実行方法

- 各フェーズでの実行内容

- ビルドのパラメータ化

- 拡張可能なフレームワーク

Mavenは、ビルド・ライフ・サイクルの主要な概念に基づいています。特定のアーティファクトまたはプロジェクトをビルドおよび配布するプロセスが明確に定義されています。

Mavenを使用する開発者の場合、任意のMavenプロジェクトのビルドを可能にする小さなコマンド・セットを学習する必要があります。Mavenプロジェクト・オブジェクト・モデル(POM)により、プロジェクトが適切にビルドされます。

次の3つの定義済の主要なライフ・サイクルがあります。

- プロジェクトをビルドするためのデフォルト

- 生成されたすべてのアーティファクトをプロジェクトから削除するためのクリーン

- プロジェクトのドキュメントをビルドするためのサイト

ビルド・ライフ・サイクルは、一連のビルド・フェーズでさらに定義されます。ビルド・フェーズは、ライフ・サイクルのステージを表します。ビルド・フェーズは、ライフ・サイクルを完了するために順に実行されます。ビルド・フェーズは、実際のタスクを実行するゴールで構成されます。標準のライフ・サイクル・フェーズにはデフォルトの一連のゴール・バインディングがあります。Mavenプラグインにより、プロジェクトにゴールを追加できます。次の表に、ビルド・フェーズおよび各フェーズの目的を示します。

ビルド・フェーズ

目的

validate

プロジェクトが適切で、必要な情報がすべて使用可能であることを確認します。

compile

プロジェクトのソースをコンパイルします。

test

適切なユニット・テスト・フレームワークを使用してコンパイル済ソース・コードをテストしますが、テストではコードをパッケージ化またはデプロイする必要はありません。

package

コンパイル済コードを取得し、配布可能な形式(JAR、WAR、EAR、SAR、GARファイルなど)にパッケージ化します。

integration-test

必要に応じて、統合テストを実行できる環境でパッケージを処理およびデプロイします。

verify

パッケージが有効で、品質基準を満たしていることを確認するチェックを実行します。

install

他のプロジェクト内の依存性としてローカルに使用するために、パッケージをローカル・リポジトリにインストールします。

deploy

最終リリースの場合は、他の開発者およびプロジェクトと共有するために、最終パッケージをリモート・リポジトリにコピーします。

標準的なMaven環境は、各開発者のローカル・マシン上のMavenインストール、企業内の共有Mavenリポジトリ・マネージャ、および依存性が格納されている1つ以上のパブリックMavenリポジトリで構成されます。主要なMavenリポジトリは、Mavenの中央リポジトリと呼ばれます。このリポジトリには、開発プロジェクト時に依存性としてよく使用される無料のオープン・ソース・ライブラリが数多く格納されています。例として、JUnitユニット・テスト・フレームワーク(Spring、Struts、その他の一般的なユーザー・インタフェース・ライブラリ)およびコード・カバレッジとスタイル・チェック・ライブラリ(CoberturaやPMDなど)があります。

1.4 Archivaを使用したリポジトリ管理

1つのプロジェクトで複数の開発者が作業する場合、企業にとって、独自の内部Mavenリポジトリを次の2つの目的で設定すると有用です。

- Mavenの中央リポジトリのように、外部バイナリ・リポジトリのプロキシまたはキャッシュとして機能することで、依存性が1回だけダウンロードされてローカルにキャッシュされ、すべての開発者がそれらを使用できるようになります。

- 開発者がビルドしたアーティファクトを格納して、他の開発者またはプロジェクトと共有できるようにします。

Mavenリポジトリは、特定のレイアウトのファイル・システム(ディレクトリ構造)と同様に単純な場合もありますが、多くの組織では、Mavenリポジトリ・マネージャと呼ばれるタイプのソフトウェアを使用するとさらに便利になります。これは、前にリストした目的に対処する際に役立ちます。このガイドでは、Mavenリポジトリ・マネージャとしてApache Archivaが使用されています。ほかにも、無料で提供されているものや市販のものを使用できます。

Archivaを使用する一般的な企業では、Archivaは開発者およびビルド・マシンがアクセス可能なサーバー上に設定されます。企業では、このサーバー上に次のリポジトリを定義します。

- Mavenの中央リポジトリのミラー

- 完了または公開された内部開発済アーティファクトを格納する内部リポジトリ

- 開発中でまだ完了していない内部開発アーティファクトを格納するスナップショット・リポジトリ

ニーズに応じて追加のリポジトリが存在する場合もあります。たとえば、特定のプロジェクト用として、または異なるライフ・サイクル・ステージに必要な様々なバージョンの依存性用として、追加リポジトリが存在する場合があります。たとえば、本番に対するバグ修正では、開発中の現在のバージョンとは異なる依存性を使用する場合があります。

すべての開発者は、外部リポジトリではなくこれらの内部リポジトリを指すようにMavenインストールを構成して、開発者が内部リポジトリにすでに格納されているアーティファクトを使用できるようにし、ダウンロード時間とビルド時間を短縮できるようにする必要があります。また、これにより、すべての開発者が様々な依存性で同じバージョンを確実に使用するようになります。

Archivaは、スナップショット・リポジトリのアーティファクトの期限切れを管理する機能も提供します。ビルドを実行するたびに、アーティファクトが作成され、スナップショット・リポジトリに格納されます。継続的インテグレーションを使用している場合は、1日に数回ビルドを実行する必要がある場合があります。ベスト・プラクティスは、これらの格納済アーティファクトを一定時間(1週間など)経過後に削除するようにArchivaを構成することです。または、各アーティファクトに関して最新のn個のバージョンのみを保持するようにArchivaを構成することもできます。いずれのアプローチも、スナップショット・アーティファクトの期限切れおよび削除を自動的に管理するのに役立ちます。

1.5 Hudsonを使用した継続的インテグレーション

Hudsonは、ビルド・プロセスの自動化を可能にする、一般的な継続的インテグレーション・サーバー製品です。通常、この自動化には次のステップが含まれます。

- 開発者がバージョン・コントロール・システムにコミットすると常にビルドを開始

- バージョン・コントロール・システムからのコードのチェックアウト

- コードのコンパイル

- ユニット・テストの実行および(多くの場合JUnitを介した)結果の照合

- デプロイ・アーカイブ形式へのコードのパッケージ化

- ランタイム環境へのパッケージのデプロイ

- 統合テストの実行および結果の照合

- Mavenスナップショット・リポジトリへのビルドのトリガー

- あらゆる問題を電子メール経由で開発者に警告

ただし、ビルド・システムを使用して、企業の標準およびベスト・プラクティスへの準拠を強制適用することもできます。たとえば、企業では、次のステップをビルド・プロセスに含めることができます。

- コード・カバレッジを実行して、適切な数のユニット・テストが存在し、実行されていることを確認

- コード品質チェックを実行して、一般的な問題を検索

- 命名規則、ネームスペースなどとの準拠を確認するためのチェックの実行

- ドキュメントがコードに含まれていることを確認するためのチェックの実行

- 承認されたバージョンの依存性が使用され、承認されていないその他の依存性は使用されていないことを確認するためのチェックの実行

HudsonではWebベースのコンソールを提供しており、ビルド・マネージャはこれを使用してビルドを定義、実行および監視できます。ビルドは、1つ以上のビルド・サーバーで実行されます。通常、ビルド・サーバーの数は、ビルドのボリューム、およびビルド完了までに予測される時間に基づいて定義されます。Hudsonは、APIも提供し、プラグイン・メカニズムを通じて拡張できるため、必要に応じて機能を追加できます。

1.6 まとめ

このガイドでは、Oracle Fusion Middleware 12cプラットフォーム上でアプリケーションを開発する大規模開発者チームをサポートする継続的インテグレーション環境を確立する方法を説明しています。この環境には、バージョン・コントロール、ビルド自動化および依存性管理用のMaven、MavenリポジトリとしてのArchiva、ビルド・プロセスを自動化するHudsonなどの継続的インテグレーション・サーバーの使用が含まれます。

このガイド内のすべての例で、Apacheツール(Subversion、Maven、ArchivaおよびHudson)を使用しています。ただし、その他の市販およびオープン・ソースの代替ツールを使用することもできます。ここでの意図は、参照可能で、他のツールに簡単に適応できる例を提供することです。たとえば、バージョン・コントロールにgitを使用したり、リポジトリ・マネージャとしてNexusを使用できます。このドキュメントでのツールの選択は、他のツールが同等の結果をもたらさないことを示唆するものではありません。

2 継続的インテグレーションのロードマップ

Oracle Fusion Middleware 12cでは、ビルド自動化および継続的インテグレーションの新機能を導入しています。継続的インテグレーションは、旅程と目的地の両方を意味します。前もってビルド・プロセスを自動化していない場合、旅程は始まったばかりです。この章では、継続的インテグレーションの達成に必要なステップの理解に役立つロードマップを提供します。

ビルド自動化および継続的インテグレーションをすでに理解している場合、この章は、Oracle Fusion Middleware 12cで提供される機能のまとめとなり、自分の経験に関連付けるのに役立ちます。

この章では、継続的インテグレーション環境参照についても説明します。これは、このガイドで説明している継続的インテグレーション・アプローチ、ツールおよび技術の採用後に環境がどのようになるかを視覚化するための例として提供されます。

この章の構成は、次のとおりです。

- 2.1項「ロードマップ」

- 2.2項「継続的インテグレーション環境参照の概要」

- 2.3項「共有ディスク・レイアウト」

2.1 ロードマップ

表2-1では、継続的インテグレーションを実装するために実行する必要がある一般的ステップについて説明し、各ステップの詳細情報の参照先も示します。

表2-1 継続的インテグレーションを達成するためのロードマップ

番号

作業

詳細情報

1.

バージョン・コントロール計画の実装

第3章では、Subversionを使用してバージョン・コントロール環境を設定する方法について説明します。

開発環境でバージョン・コントロールを現在使用していない場合は、第3章で説明しているリポジトリ・レイアウト、Subversionワークフロー、およびタグ付けと分岐に特に注意する必要があります。

Subversionを使用したバージョン・コントロールの詳細は、次を参照してください。

http://svnbook.red-bean.com

2.

バイナリ・リポジトリ計画の実装

第4章では、Apache Archivaを使用してバイナリ・アーティファクト(自分がビルドするアーティファクト、およびビルドが依存しているアーティファクトの両方)用のリポジトリを設定する方法について説明します。複数のリポジトリの必要性の理解、スナップショットと他のリポジトリとの間の相違の理解、およびリポジトリに必要な管理とメンテナンスに特に注意する必要があります。

3.

ビルド自動化および依存性管理計画の実装

第5章では、Mavenおよびインストールと構成ステップについて簡単に説明します。これまでMavenを使用したことがない場合は、Mavenを理解するために参考資料を読んでおく必要があります。次の公式Maven Webサイトにある「What is Maven?」をまず読んでください。

http://maven.apache.org/what-is-maven.html

次を含む多数のリソースをオンラインで使用することもできます。

- 次のサイトにある「Maven By Example」および「Maven: The Complete Reference」
http://www.sonatype.org/maven

- 次のサイトにある「Better Builds with Maven」
http://www.maestrodev.com/better-builds-with-maven/about-this-guide/

これらのリソースは、Mavenの使用方法、その設計の背後にある原理の一部、およびMavenを使用してどのような種類の作業を実行できるかについて包括的理解を形成するのに役立ちます。

4.

リポジトリへのOracleアーティファクトの移入

5.3項では、MavenリポジトリにOracle提供アーティファクトを移入する方法について説明します。Oracle Maven同期プラグイン、Oracleランタイム環境にパッチを適用した場合の影響、ビルド環境でパッチを実行する意味、および原型の役割を理解することに特に注意する必要があります。

5.

Mavenバージョン番号を理解していることを確認

第7章では、Mavenバージョン番号の重要な意味合いについて説明します。Mavenバージョン番号の使用方法、依存性を指定するためのバージョン番号範囲、およびバージョン番号の指定方法に基づいてMavenで依存性を解決する方法について理解していることを確認してください。

6.

Mavenを使用してWebLogic Server用のJava EEアプリケーションをビルドする方法の学習

第9章では、Oracle WebLogic Maven原型を使用してJava EEアプリケーションを作成する方法、およびアプリケーションをコンパイル、パッケージ化して、WebLogic Serverにデプロイする方法について説明します。

7.

Mavenを使用してCoherenceアプリケーションをビルドする方法の学習

第10章では、Oracle Coherence Maven原型を使用してCoherence GARアプリケーションを作成する方法、およびアプリケーションをコンパイル、パッケージ化して、WebLogic Server上のCoherenceコンテナにデプロイする方法について説明します。

8.

Mavenを使用してアプリケーション全体をビルドする方法の学習

第11章では、これらの多くの概念をまとめてより現実的なアプリケーションをビルドする方法について説明します。アプリケーション例には複数のコンポーネント部品が含まれ、それぞれが異なるOracle Fusion Middlewareランタイム環境を対象としています。コンポーネント間の依存性、およびカスタム・パッケージ化要件もあります。

9.

Maven POM継承を使用してビルド・プロセスをカスタマイズする方法の学習

第8章では、Oracle Fusion Middleware 12cに含まれるMaven POM階層について説明します。一般的なOracleの親POMでは、ビルド・システムを簡単にカスタマイズする方法が提供されます。

10.

継続的インテグレーション計画の実装

第6章では、継続的インテグレーションを実行する環境を作成するようにHudsonを設定する方法について説明します。第10章では、継続的インテグレーション環境を確立および運用するための重要な考慮事項の詳細について説明します。

2.2 継続的インテグレーション環境参照の概要

この章では、Subversion、Maven、HudsonおよびArchivaに基づいた継続的インテグレーション環境の参照実装について説明します。

図2-1に、推奨される開発環境の概要を示します。(中央に示された)濃い青のコンポーネントは、開発環境の共有(サーバー)部分を構成しています。

図2-1 継続的インテグレーション環境参照のアーキテクチャ

次に、環境の説明を示します。

- 開発者のマシン: 各開発者はワークステーションを保有し、そこで統合開発環境(Oracle JDeveloper)を実行して、Javaコード、デプロイメント・ディスクリプタ、BPELプロセス、ADFユーザー・インタフェース・プロジェクトなどのソース・アーティファクトを作成します。JDeveloperにはSubversionクライアントが含まれています。これにより、開発者はSubversionサーバー上でのコードのチェックインやチェックアウト、相違のチェック、マージの実行、競合の解決などのアクションを実行できます。各開発者のマシンには、それぞれのワークステーション上のローカルMavenリポジトリも含まれており、このリポジトリには、開発者が自分のワークステーションで実行する必要があるローカル・ビルドの実行に必要な依存性が保持されています。たとえば、開発者は、共有Subversionサーバーにコードをチェックインする前に、ビルドをチェックし、ユニット・テストをローカルで実行する必要がある場合があります。

- Mavenリポジトリ・マネージャ: 開発環境のこの部分は、ビルドされたすべてのアーティファクトと依存性(自分の環境で作成された場合とソースが外部である場合の両方)用のリポジトリです。通常は、次のように目的に応じて異なるリポジトリが存在します。

- バイナリ・リポジトリ・マネージャは、外部Mavenリポジトリ(Mavenの中央リポジトリなど)のミラーまたはプロキシとして機能します。これらのリポジトリからのアーティファクトがビルドに必要な場合は、ダウンロードされ、Mavenリポジトリ・マネージャによって管理されているリポジトリに格納されます。

- アーティファクト(WAR、JAR、SARファイルなど)をビルドすると、Mavenリポジトリ・マネージャによって管理されるリポジトリに公開されます。多くの場合、SNAPSHOT(作業中)アーティファクト用およびリリース(最終)アーティファクト用に個別のリポジトリがあります。

- Subversionサーバー: 開発者が作成したソース・アーティファクトのリポジトリです。通常は、複数のリポジトリがあります。たとえば、プロジェクトごとに1つ存在する場合があります。

- Hudson継続的インテグレーション(親)サーバー: 継続的インテグレーション・ビルドを管理するサーバーです。ビルドの実行、およびこれらのビルドの結果の収集とレポートを担当します。

- Hudson子サーバー: 追加機能を提供するために使用される、オプションの追加Hudsonサーバーです。多数のビルドを実行する場合、一部のビルドを共有または実行するように複数のHudson子サーバーを設定できます。

- ファイル・サーバー: Hudsonビルド・サーバーで必要となる製品バイナリのコピーをホストする、ストレージ・エリア・ネットワーク(SAN)やネットワーク・アタッチ・ストレージ(NAS)などです。たとえば、Oracle ADFアプリケーションをビルドするにはojdeployが必要です。すべてのHudsonサーバーが、このファイル・サーバーにアクセスできます。

- テスト・サーバー(図示されていません): 統合テストを実行する場合は、WAR、JAR、SARなどのビルド済アーティファクトをデプロイし、統合テストを実行する一連のテスト・サーバーも存在する場合があります。

- Mavenの中央リポジトリ: これは、ビルドに必要となる場合があるオープン・ソース依存性を保持する外部Mavenリポジトリです。Mavenリポジトリ・マネージャは、独自のリポジトリに存在しない依存性をこれらのリポジトリ内で検索し、使用可能な場合はその依存性を取得できます。

環境のサイズによっては、これらのコンポーネント(外部コンポーネントおよび開発者のマシンは除く)が単一サーバー上にあるか、または複数のマシンに分散している場合があります。

2.3 共有ディスク・レイアウト

共有ディスクを使用する予定がある場合は、Subversion、Maven、Hudsonデータおよび製品バイナリをすべて共有ディスクに保持することを検討します。

推奨されるディレクトリ構造を図2-2に示します。この構造では、確実に作成すると考えられる概要レベルのディレクトリのみを示しています。

図2-2 共有ディスクのディレクトリ構造

製品バイナリの場合、環境(本番、開発、QAなど)ごとに1つのコピーを保持する必要があることに注意してください。製品バイナリは同じバージョンのソフトウェアですが、異なるパッチがインストールされている場合があります。デプロイ先の環境として、常に同じ(パッチ適用済の)アーティファクトのセットを使用してビルドできるようにします。

図2-2の例のように開発環境が12.1.3まで移行している場合であっても、依然として12.1.2に対するビルドを実行できる必要があります。本番またはQAでバグが見つかった場合は、これらの環境にインストールしたのと同じバージョンのアーティファクトを使用してビルドできる必要があります。

Mavenリポジトリ・マネージャ(この場合はArchiva)のリポジトリを次に示します。

- 内部: 開発環境でビルドした最終アーティファクトを格納します。

- スナップショット: 開発環境でビルドした作業中のアーティファクトを格納します。

- ミラー: 外部リポジトリからダウンロードした依存性を格納します。

- 開発、テスト、QA、本番: 必要な依存性を格納するために、ターゲット環境ごとに1つのリポジトリを準備します。このようにするのは、2つの環境に同じバージョンのアーティファクト(12.1.3-0-0など)があるが、一方の環境ではそのアーティファクトにパッチが適用されているため、相違が発生することがあるためです。この要件の詳細は、5.3.7項を参照してください。

共有ディスク・サーバーは、製品バイナリ、Subversionリポジトリ、Archivaリポジトリ、Mavenバイナリ、Hudsonバイナリ、構成およびファイル記憶域用に十分な領域を提供する必要があります。少なくとも、40GB以上を割り当てることをお薦めします。Archivaスナップショット・クリーンアップ・ルール、ソース・コントロール・システムへのバイナリのチェックインを許可するかどうかなどの要因によって、必要な領域が増える場合があります。

3 バージョン・コントロールのためのSubversionのインストールおよび構成

Subversionは、ファイルやフォルダまたはディレクトリに対する変更を追跡するバージョン・コントロール・システムで、データ・リカバリを容易にし、経時的な変更の履歴を提供します。この章では、バージョン・コントロールのためのSubversionのインストールおよび構成方法について説明します。

この章の構成は、次のとおりです。

- 3.1項「Subversionのダウンロード」

- 3.2項「Subversionのインストール」

- 3.3項「サービスとしてのSubversionサーバーの構成」

- 3.4項「リポジトリの設定」

- 3.5項「SVNワークフローの理解」

- 3.6項「タグ付けと分岐に関する考慮事項」

- 3.7項「Subversionクライアント」

- 3.8項「詳細情報」

3.1 Subversionのダウンロード

SubversionはApacheプロジェクトですが、Apacheではオペレーティング・システム用の独自のバイナリ・ファイルをビルドしていません。次のURLに、サード・パーティによってビルドされた全主要オペレーティング・システム用のSubversion最新安定リリースに関するURLが示されています。

http://subversion.apache.org/packages.html

可能な場合には、YUMやAPTなどのパッケージ・マネージャを使用して、他のソフトウェアのインストールを管理してください。

Windowsオペレーティング・システムの場合は、次のURLで入手可能なSilk SVNなどのプリコンパイル済バイナリ・パッケージを使用することをお薦めします。

http://www.silksvn.com/en/download

Windowsで、インストーラ・パッケージを使用してSubversionをインストールする場合は、サーバー・バイナリ・ファイルを含むインストーラを選択するようにしてください。

3.2 Subversionのインストール

インストール方法は、プラットフォームおよび配布方法によって異なります。

たとえば、YUMを使用する場合、コマンドは次のようになります。

sudo yum install subversion

Windowsの場合、デフォルトのインストール・パスをより短い場所に変更できます。

C:\svn

PATH変数がインストーラによって正しく設定されていることを確認します。

svnserveのバージョン情報を取得するには、コマンドラインで次のコマンドを実行します。

svnserve --version

コマンドが見つからない場合は、次の手順を実行します。

1. 「コントロール パネル」を開きます。

2. 「システム」→「システムの詳細設定」の順に選択します。

3. 「詳細設定」で、「環境変数」を選択します。

4. Subversionバイナリ・ディレクトリへのパスを追加して、「システム環境変数」ペインのPATH変数を編集します。

3.3 サービスとしてのSubversionサーバーの構成

Subversionサーバーをサービスとして構成するには、次の手順を実行します。

- Linuxの場合
Linuxインストール・プロセスによって、自動的に/etc/init.d/svnserveスクリプトが作成されます。このスクリプトにより、システムの起動時にサーバーが起動します。

サービスを手動で開始するには、コマンドラインで次のコマンドを実行します。

sudo /etc/init.d/svnserve start

- Windowsの場合
サービス・マネージャにsvnserveを登録する必要があります。svnserveを登録するには、次のコマンドを実行します。

sc create svnserver binpath= "C:\svn\svnserve.exe" --service -r "REPOS_PATH" displayname="Subversion" depend=Tcpip start=auto

前述のコマンドで、REPOS_PATHはローカル・ファイル・システムへの絶対パスです。

3.4 リポジトリの設定

Subversionリポジトリは、バージョン作成されている、Subversionサーバー上のアーティファクトの集まりです。

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

- リポジトリの作成

- Subversionのレイアウト

- 既存プロジェクトのインポート

3.4.1 リポジトリの作成

Subversionのインストール後、リポジトリを作成する必要があります。svnadminという名前のコマンドライン・ユーティリティは、サーバー側の管理操作の主要ツールです。

- Linuxの場合
リポジトリを生成するには:

1. 次のコマンドを実行して、リポジトリ用のディレクトリを作成します。

mkdir -p REPOS_PATH

このコマンドのREPOS_PATHは、ローカル・ファイル・システムへの絶対パスです。

次に例を示します。

mkdir –p /ciroot/subversion/repository

2. 次のコマンドを実行して、指定パスにリポジトリを作成します。

svnadmin create REPOS_PATH

このコマンドのREPOS_PATHは、ローカル・ファイル・システムへの絶対パスです。

次に例を示します。

svnadmin create /ciroot/subversion/repository

- Windowsの場合
リポジトリを生成するには:

1. 次のコマンドを実行して、リポジトリ用のディレクトリを作成します。

mkdir REPOS_PATH

このコマンドのREPOS_PATHは、ローカル・ファイル・システムへの絶対パスです。

次に例を示します。

mkdir C:\ciroot\subversion\repository

2. 次のコマンドを実行して、指定パスにリポジトリを作成します。

svnadmin create REPOS_PATH

このコマンドのREPOS_PATHは、ローカル・ファイル・システムへの絶対パスです。

次に例を示します。

svnadmin create C:\ciroot\subversion\repository

リポジトリへのアクセスは、ファイル許可と、SVNクライアントを介してリポジトリにアクセスするために参照されるユーザーよって制御されます。新規リポジトリ内のすべてのファイルについて、ユーザーおよびグループ許可が、リポジトリの内容に対するアクセス制御のタイプを反映していることを確認します。

デフォルトでは、新規リポジトリに対して匿名の読取り専用アクセスが有効になります。つまり、SSHアクセスを持つどのユーザーでも、リポジトリの許可設定に関係なく、リポジトリ・ファイルをチェックアウトできることになります。これは、REPOS_PATH/conf/svnserve.confファイルで変更できます。

これでリポジトリの作成が完了し、次の基本URLを使用することで、新規リポジトリに対する標準操作をSubversionクライアントで実行できます。

svn+ssh://USER@HOST/REPOS_PATH

次に例を示します。

svn ls svn+ssh://mycompany@localhost/ciroot/subversion/repository

svn+ssh以外にも、Subversionによってサポートされている他のプロトコルが複数あります。他のプロトコルを構成する方法については、Subversionのマニュアルを参照してください。デフォルトでは、Windowsでsvn+sshは使用できないことがあります。

3.4.2 Subversionのレイアウト

Subversionではリポジトリ内に特定のサブディレクトリ構造は必要ありませんが、このマニュアルで行われているように、規定の表記規則に従うことをお薦めします。一般的なリポジトリ・レイアウトは次のようになります。

主要なコード行の開発はtrunkディレクトリで行われます。リリースが実行されると、現在のトランク・ソースが、tagsディレクトリの、そのリリースに対応するタグにコピーされます。Subversionのコピー操作は、サーバーが内部的に変更を追跡するため、記憶域の点で高価ではありません。

次にタグの例を示します。

my-project/tags/3.0.5

前述の例の場合、3.0.5は、このタグが対応しているリリース・バージョンを示します。

タグは、パッチ作成またはバグ修正のリリースに必要になる可能性のある、将来的な作業に重要です。リリース・タグのもう1つの重要な点は、関連リリースの問題に関する調査が容易になることです。

タグのパッチやそれに続く変更が必要とみなされた場合は、分岐の作成が必要になります。分岐はリポジトリ内の他の場所のコピーで、タグとは構成が異なります。タグのコピーをbranchesディレクトリに作成した後、コードをチェックアウトしたり、必要に応じて変更することができます。変更が完了すると、新しいリリースが分岐から作成され、対応するタグが作成されます。

このProject-Aの例は、ソース・コードのパッチ管理に関する一般的なワークフローの概要を示しています。

Project-Aの場合、主要なコード行はproject-A/trunkで管理されます。trunkディレクトリで現在開発されているバージョンは、バージョン2.1です。Project-Aには前のリリースが3つあり、1.0、1.1および2.0です。バージョン1.0でパッチ・リリースを必要とする問題が検出されています。

この問題に対応するために、svn copyコマンドを使用して、project-A/branches/1.0.1-SNAPSHOTにproject-A/tags/1.0タグがコピーされています。次の図に示すように、SNAPSHOT指定はまだリリースされていないバージョンを示すMavenの仕組みです。

分岐のコード修正が完了すると、その分岐はproject-A/branches/1.0.1-SNAPSHOTからproject-A/tags/1.0.1タグにコピーされます。その後、このタグからリリース・ビルドを実行できます。

ディレクトリ構造の表記規則の詳細は、次のURLにある『Subversionによるバージョン管理』の第2章を参照してください。

http://svnbook.red-bean.com/

3.4.3 既存プロジェクトのインポート

リポジトリ内に管理の必要な既存プロジェクトがある場合、SVNクライアントのimportコマンドを使用して、これらをインポートできます。

svn import LOCAL_PATH REPOSITORY_URL/REPOSITORY_PATH

次に例を示します。

svn import /checkouts/project-a svn+ssh://user@svn.mycompany.com/ciroot/subversion/repository/project-a/trunk/ -m "initial import"

3.5 SVNワークフローの理解

コードを変更するには、通常、次の操作を実行します。

1. svn updateコマンドを使用して作業コピーを更新します。

2. 変更を行います。必要に応じて、svn add、svn delete、svn copyおよびsvn moveコマンドを使用し、ファイルを編集します。

3. svn statusおよびsvn diffコマンドを使用して、変更を確認します。

4. 間違いを修正します。svn revertコマンドを使用すると、変更を取り消したり、中止することができます。

5. 競合を解決します。競合が解決したら、svn resolveコマンドを使用してマークを付けます。

6. svn commitまたはsvn ciコマンドを使用して、変更をコミットします。

図3-1は、SVN操作の完全なライフサイクルを示しています。

図3-1 SVNワークフロー

継続的インテグレーションの開発プロセスでは、このワークフローはおおむね変わりません。非継続的インテグレーション・プロセスよりも、コミットされる変更のセットが小さく、より頻繁に発生する傾向があります。継続的インテグレーション・システムでインテグレーション・ビルドを実行できるように、ターゲット・リリース用のアクティブなトランクまたは分岐コードをコミットする必要があります。将来的にメインライン・コード・ベースにマージすることを意図した個人的な分岐の作成は避けてください。個人的な分岐およびマージの手法は統合を遅らせるもので、継続的インテグレーションの原則に反します。

Subversionで管理されたプロジェクトの作業を開始するには、最初にファイルをローカル・ファイル・システムにチェックアウトする必要があります。SVNクライアントによって、各サブディレクトの.svnディレクトリにあるSubversionメタデータなどのプロジェクト・ファイルがシステムにコピーされます。次のコマンドを実行して、ファイルをチェックアウトします。

svn co REPOSITORY_URL/REPOSITORY_PATH LOCAL_DIRECTORY

このコマンドの内容は次のとおりです。

- REPOSITORY_URLは、SubversionリポジトリへのURLです。

- REPOSITORY_PATHは、チェックアウトされるディレクトリへのパスです。

- LOCAL_DIRECTORYは、チェックアウトされたプロジェクトが格納されるローカル・ディレクトリへのパスです。

test-projectの例は、プロジェクトのメインライン・コード開発を示しています。

svn checkout
svn+ssh://user@svn.mycompany.com/subversion/repository/test-project/trunk test-project

この場合、test-projectというディレクトリが作成され、プロジェクトの内容は再帰的にサーバーからディレクトリにコピーされます。

チェックアウトされたファイルに対していくつでも変更を行うことができます。リポジトリに変更をコミットする準備が整ったら、コミットするファイルまたはディレクトリをチェックインします。すべてのコンポーネントがチェックアウトされるディレクトリのメンバーであるかぎり、チェックインされるファイルまたはディレクトリのセットが、チェックアウトされたファイルまたはディレクトリのセットに対応している必要はありません。次のコマンドを実行して変更をコミットします。

svn commit -m "Added code and test case" test-project/src/main/java
test-project/src/test/resources/testdata.xml

チェックアウトまたは最後の更新とコミットの間に変更が行われた場合、操作は失敗し、理由を説明するメッセージが表示されます。競合を解決し、競合が解決済としてマークされるようにシステムを更新する必要があります。これを行うには、競合を解決して、次のコマンドを実行します。

svn resolve test-project/src/test/resources/testdata.xml

競合を解決した後、通常のチェックイン操作を続行します。

プロジェクトがいったんシステムにチェックアウトされた後は、そのソース・コードに対する後続のチェックアウトを実行する必要がなくなります。Subversionリポジトリの内容との同期を維持するために、チェックアウトされたディレクトリ、さらには個々のファイルに対してsvn updateを実行できます。

リポジトリにローカル変更をコミットする操作の前に、svn updateコマンドを実行して、最後のチェックアウトまたは更新以降に、他のユーザーによってコードにコミットされた変更を統合します。

svn update

最後に、次のコマンドを実行して変更をコミットします。

svn commit -m "description of the updates"

3.6 タグ付けと分岐に関する考慮事項

タグ付けによって分岐の名前付きポイント・イン・タイム・コピーが作成されます。タグ付けは次の2つの場合に必ず実行する必要があります。

- プロジェクトがリリースされた場合

- 重要なマイル・ストーンが発生した場合

リリースにタグを付けることが重要ですが、これは、タグによってパッチ適用リリースのための簡単なメカニズムが提供されるためです。あるリリースに不具合が見つかった場合、そのリリースのタグから分岐して、修正を行い、そのリリースのパッチを作成できます。後でこの新しい(パッチ適用済の)リリースに問題が見つかり、新しい問題に対する修正が必要になった場合には、このリリースにも同様にタグを付けます。

リリースにタグを付けなかった場合、そのリリースにビルドされている正確なコード行の取得が非常に難しくなります。

注意:

タグ付きリリースは読取り専用アーティファクトとして取り扱います。タグを付けた後にリリースに対するマージを続行しないようにしてください。

3.7 Subversionクライアント

この項では、2つの一般的なSubversionクライアントについて説明します。

- WebSVN

- TortoiseSVN

3.7.1 WebSVN

WebSVNは、リポジトリに対するWebベースのビューを提供し、視覚的な差分、注釈および検索をサポートします。

WebSVNは次の場所からダウンロードできます。

http://www.websvn.info/

3.7.2 TortoiseSVN

TortoiseSVNは、Windowsエクスプローラと統合されるフリーのWindows Subversionクライアントです。標準的なSubversionクライアントのすべての操作をWindowsユーザー・インタフェースで実行できます。フォルダおよびファイル・アイコンのデコレータは、Subversionファイルのステータスを示します。コマンドライン・ツールはメニュー項目にマップされ、オプションはダイアログ・ボックスを介して構成可能です。また、Tortoiseでは高度でグラフィカルな差分と、競合の解決に役立つマージ・ツールも提供しています。

TortoiseSVNは次の場所からダウンロードできます。

http://tortoisesvn.net/

3.8 詳細情報

このマニュアルは、Subversionを開始および実行するための簡易ガイドとして作成されています。詳細は、次の場所にある『Subversionによるバージョン管理』を参照してください。

http://svnbook.red-bean.com

注意:

Subversionの知識がない場合は、『Subversionによるバージョン管理』を読むことをお薦めします。

4 Archiva Mavenリポジトリ・マネージャのインストールおよび構成

この章では、Apache Archivaのインストールおよび基本構成について説明します。Archivaは、アーティファクト・リポジトリの複数ある選択肢の1つであり、Mavenベースの継続的インテグレーション・ビルド・システムの重要なコンポーネントです。

Mavenリポジトリ・マネージャまたはアーティファクト・リポジトリについて精通していない場合は、1.4項を参照してください。

Archiva(この章で説明)およびMaven(第5章で説明)のインストールおよび構成を完了した後で、Oracle提供のアーティファクトをArchivaリポジトリに移入する必要があります。詳細は、5.3項を参照してください。

この章の構成は、次のとおりです。

- 4.1項「Archivaの概要」

- 4.2項「Archivaのダウンロード」

- 4.3項「Archivaのインストール」

- 4.4項「Archivaの構成」

- 4.5項「詳細情報」

- 4.6項「Mavenリポジトリ・マネージャ管理」

4.1 Archivaの概要

Archivaは、スタンドアロン・インストールとしてJettyにバンドルされて配布されます。WARファイル配布も提供されるため、Archivaを既存のアプリケーション・サーバーにインストールできます。

この章では、スタンドアロン・バージョンのインストール・プロセスについて説明します。WARファイルのインストールおよび構成に関する指示は、次の場所にある公式Archivaドキュメントで提供されています。

http://archiva.apache.org/docs/1.3.6

4.2 Archivaのダウンロード

最新のスタンドアロンArchivaリリースを.zipファイルまたはtar.gzファイルとして次の場所からダウンロードできます。

http://archiva.apache.org/download.html

4.3 Archivaのインストール

配布をターゲット・インストール・ディレクトリに解凍します。この場所は、プリファレンスおよびターゲット・オペレーテイング・システムによって異なります。継続的インテグレーション関連のワークスペース用に共通の場所を作成することをお薦めします。たとえば、次の場所に配布を解凍します。

/ciroot/archiva

- Linuxの場合
次のコマンドを実行します。

sudo mkdir -p /ciroot/archiva ; sudo tar xzvf apache-archiva-1.3.6-bin.tar.gz
--strip-components 1 -C /ciroot/archiva

コマンドを実行した後、自分のユーザーおよびグループに一致するようにファイルの所有者を変更する必要があります。たとえば、oracleをユーザーIDとして使用し、oracleをグループ名として使用している場合は、次のコマンドを実行します。

chown -R oracle:oracle /ciroot/archiva

- Windowsの場合
次のように、Archivaインストール・ファイルを作成するためのディレクトリを作成します。

mkdir c:\ciroot\archiva

ダウンロードしたArchiva zipファイルを新しいディレクトリに抽出します。

4.4 Archivaの構成

この項では、Archivaの構成方法について、一般的な説明だけでなく、Fusion Middleware環境で使用するための具体的な構成についてもいくつか説明します。

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

- サーバーの構成

- サーバーの起動

- 管理者ユーザーの作成

- 内部リポジトリおよびスナップショット・リポジトリ

- プロキシ・リポジトリ

- ミラー・リポジトリの構成

- 開発、本番、品質保証およびテストのリポジトリの作成

- デプロイメント可能ユーザーの作成

4.4.1 サーバーの構成

Archiva Jettyインスタンスは、デフォルトHTTPポートの8080で起動します。これを変更する場合は、/ciroot/archiva/conf/jetty.xmlを変更します。次のように、jetty.portのコネクタ構成のSystemProperty値を異なる値(8081など)に変更します。

次に例を示します。

<Call name="addConnector">
<Arg>
<New class="org.mortbay.jetty.nio.SelectChannelConnector">
<Set name="host">
<SystemProperty name="jetty.host"/>
</Set>
<Set name="port">
<SystemProperty name="jetty.port" default="8081"/>
</Set>

4.4.2 サーバーの起動

サーバーを構成した後は、そのサーバーをコマンドライン・インタフェースから起動できます。

サーバーを起動するには、次の手順を実行します。

- 次のコマンドを実行します。

/ciroot/archiva/bin/archiva start

64ビットLinuxシステムでは、次のようなエラー・メッセージを受信する場合があります。

./archiva: /ciroot/archiva/bin/./wrapper-linux-x86-32:
/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

このエラーが表示された場合は、glibc.i686パッケージを(yumなどを使用して)インストールし、再試行します。

- 次のコマンドをコマンドラインで実行して、サーバー起動中のログ出力をチェックし、予期したとおりに起動していることを確認します。

tail -f /ciroot/archiva/logs/*

起動タスクが完了すると、Archivaサーバーは次の場所で使用可能になります。

http://localhost:8081/archiva

4.4.3 管理者ユーザーの作成

Archivaホーム・ページに最初にアクセスすると、管理者パスワードを設定するよう求められます。管理者ユーザーのフルネーム、電子メール・アドレスおよびパスワードを指定します。

4.4.4 内部リポジトリおよびスナップショット・リポジトリ

Archivaは、ホストされている構成済の次の2つのリポジトリで起動します。

- 内部
内部リポジトリは、組織によってデプロイされた固定バージョンのリリース・アーティファクトを保持するリポジトリであり、完了バージョンのアーティファクト、開発されなくなったバージョン、およびリリース済のバージョンが含まれます。同じアーティファクトの開発中バージョンがスナップショット・リポジトリに今後存在する可能性があることに注意してください。

- スナップショット
スナップショット・リポジトリでは、接尾辞SNAPSHOTが付いたバージョンとして示される作業中のアーティファクト、およびまだリリースされていないアーティファクトが保持されます。

4.4.5 プロキシ・リポジトリ

内部リポジトリは、内部的にデプロイされたアーティファクトのホスティングに加えて、パブリックMaven中央リポジトリとして機能するようにデフォルトで構成されます。プロキシ・リポジトリは、サード・パーティのリポジトリを直接参照するかわりに使用できます。プロキシでは、前に要求されたアーティファクトがローカルにキャッシュされます。これにより、共有サーバーでの負荷が軽減されるため、空のリポジトリからビルドを実行する場合は特に推奨される方法です。共有サーバーに負荷をかけすぎると、ホストからの追加要求が抑制されたり禁止される場合があります。ビルド・パフォーマンスを大幅に向上させるには、負荷が少ない近接のプロキシ・サーバーから依存性をフェッチします。

他のパブリック・リポジトリからのサード・パーティ・アーティファクトが必要な場合は、それらを追加のプロキシ・コネクタとして自分のリポジトリに追加します。

4.4.6 ミラー・リポジトリの構成

通常はキャッシュされたサード・パーティのプロキシ・アーティファクトを複数のリポジトリ間で共有する必要があるため、キャッシュされたアーティファクトを個別のリポジトリに移動して、プロジェクト・アーティファクトから分離する必要があります。

ミラー・リポジトリを作成するには、次の手順を実行します。

1. プロキシ接続を内部リポジトリから削除します。

1. 「Administration」メニューで、「Proxy Connections」をクリックします。

2. 各エントリの赤いXをクリックして、「Central Repository」および「maven2-repository.dev.java.net」プロキシ・コネクタを削除します。

2. 新しいミラー・リポジトリを追加します。

1. 「Administration」メニューで、「Repositories」をクリックします。

2. 右上隅にある「Add」をクリックします。

3. 「Admin: Add Managed Repository」ダイアログ・ボックスで、次の情報を指定します。

- Identifier: mirror

- Name: Mirror

- Directory: /ciroot/archiva/data/repositories/mirror

- 「Releases Included」、「Block Re-deployment of Released Artifacts」および「Scannable」を選択します。

4. 「Add Repository」をクリックします。

3. プロキシ・コネクタをミラー・リポジトリに追加します。

1. 「Administration」メニューで、「Proxy Connections」をクリックします。

2. 「Add」をクリックします。

3. 「Managed Repository」で「mirror」を選択します。

4. 「Remote Repository」で「central」を選択します。

5. 「Add Proxy Connector」をクリックします。

ミラー・リポジトリをリモート・リポジトリに構成する場合は、手順1から3を完了します。ただし、手順1-bでは「maven2-repository.dev.java.net」を選択します。

これらの手順を完了すると、次のように表示されます。

新しいリポジトリの読取り権限を付与するように匿名ゲスト・ユーザーを構成するには、次の手順を実行します。

1. 「Management」メニューで、「User Management」をクリックします。

2. 「Guest」をクリックします。

3. 「Edit Roles」をクリックします。

4. 「mirror」の横の「Repository Observer」ロールを選択します。

5. 「送信」をクリックして変更を保存します。

4.4.7 開発、本番、品質保証およびテストのリポジトリの作成

Mavenビルドで対象とするOracle Fusion Middleware環境ごとに個別のリポジトリを作成する必要があります。Oracleによる個別パッチ適用(5.3.7項を参照)のサポートとは、バージョンが同じであるが、適用されている個別パッチが異なるため一部のファイルが異なるという、2つの異なる環境(本番とテストなど)を使用できることを意味します。

Mavenビルドで適切なバージョンのファイルを使用するには、各ターゲット環境にMavenリポジトリを作成および構成し、グループを作成します。

1. 次のようにリポジトリを作成します。

1. 「Administration」メニューで、「Repositories」をクリックします。

2. 新しいリポジトリを追加するには、右上隅にある「Add」をクリックします。

3. 「Admin: Add Managed Repository」ダイアログ・ボックスで、次の詳細情報を指定します。

- Identifier: dev、prod、qa、testなどの識別子を指定します。

- Name: 名前を指定します。

- Directory: /ciroot/archiva/data/repositories/${IDENTIFIER}などのディレクトリ・パスを追加します(ここで、${IDENTIFIER}は、「Identifier」で指定した文字列と一致します)。

- 「Block Re-deployment of Released Artifacts」を選択解除します。

- 「Releases Included」および「Scannable」を選択します。

4. 「Add Repository」をクリックします。

2. 新しいリポジトリの読取り権限を付与するように匿名ゲスト・ユーザーを構成するには、次の手順を実行します。

1. 「Manage」で、「User Management」をクリックします。

2. 「guest」を選択します。

3. 「Edit Roles」を選択します。

4. 該当するリポジトリ・エントリの横にある「Repository Observer」ロールを選択します。

5. 「送信」をクリックして変更を保存します。

3. 新しいリポジトリに対応するグループを作成するには、次の手順を実行します。

1. 「Administration」メニューで、「Repository Groups」をクリックします。

2. 右上隅にある「Add Group」をクリックします。

3. 「Identifier」フィールドで、作成したリポジトリと一致する名前に-groupを付けて(dev-groupなど)指定します。

4. 「Add Group」をクリックします。

5. 「Add Repository」の横にあるドロップダウン・メニューから新しいリポジトリ(devなど)を選択し、「Add Repository」をクリックします。
手順3-aから3-dまでを繰り返し、mirrorおよびsnapshotsを追加します。

次の図は、「Repository Groups」ページを示しています。

4. リポジトリとグループの作成手順1から3を、リポジトリ・タイプ(test、qaおよびprod)ごとに繰り返します。

4.4.8 デプロイメント可能ユーザーの作成

内部リポジトリへのデプロイメントをサポートするには、適切な権限を持つユーザーを少なくとも1人は追加する必要があります。

1. 「Management」で、「User Management」をクリックします。

2. 「Create New User」をクリックして、ユーザーを追加します。次に、名前、メール・アドレス、パスワードなどの必要な詳細を指定します。ユーザーが追加されると、そのユーザーの「Role Administration」ダイアログ・ボックスが表示されます。

3. 「Role Administration」ダイアログ・ボックスの「Resource Roles」で、「Snapshot」および「Internal Repositories」に対して「Repository Manager」ロールを選択します。

4. 「送信」をクリックして変更を保存します。

注意:

Repository Managerロールでは、アーティファクトをアップロードできるだけでなく、リポジトリ構成を変更することもできます。

ロールをカスタマイズまたは変更するには、「User Roles」セクションで、より制限された新しいロールを追加し、それを該当するユーザーに割り当てます。

通常、リポジトリへのアクセス権を持つ各個人用に新しいユーザーを作成します。Hudsonの場合、リポジトリへのビルド出力を公開するには、リポジトリにアクセスする各ユーザーは独自のユーザーIDを持つ必要があり、デプロイ権限を持つ追加ユーザーの作成も必要となります。

Archiva(この章で説明)およびMaven(第5章で説明)のインストールおよび構成を完了した後で、Oracle提供のアーティファクトをArchivaリポジトリに移入する必要があります(5.3項で説明)。

4.5 詳細情報

Archiva 1.3.6のユーザー・ガイドは、次の場所にあります。

http://archiva.apache.org/docs/1.3.6/userguide/

その他のリリースについては、次に示すArchivaホーム・ページで参照できます。

http://archiva.apache.org

4.6 Mavenリポジトリ・マネージャ管理

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

- スナップショット・クリーンアップ

- 高度なユーザー管理

- Archivaのバックアップ

- Archivaのフェイルオーバー

4.6.1 スナップショット・クリーンアップ

Archivaは、正常にデプロイされたジョブごとに特定のスナップショット・バージョン・アーティファクトのインスタンスを保持します。スナップショット・アーティファクトを要求すると、最新のスナップショットが取得されます。Mavenでは、リポジトリ内の関連するメタデータを調べて、ダウンロードする適切なコピーを識別します。Mavenリポジトリ・マネージャは、各コピーを一意のタイムスタンプとビルド番号を使用して保持します。

たとえば、アーティファクトのリポジトリ・ディレクトリの内容は、次のようになります。

maven-metadata.xml
test-artifact-2.1-20110928.112713-14.jar
test-artifact-2.1-20110928.112713-14.pom
test-artifact-2.1-20110924.121415-13.pom
test-artifact-2.1-20110924.121415-13.jar

対応するリポジトリ・メタデータは、次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>com.my.company</groupId>
<artifactId>test-artifact</artifactId>
<version>2.1-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20110928.112713</timestamp>
<buildNumber>14</buildNumber>
</snapshot>
<lastUpdated>20110928112718</lastUpdated>
<snapshotVersions>
<snapshotVersion>
<extension>jar</extension>
<value>2.1-20110928.112713-14</value>
<updated>20110928112713</updated>
</snapshotVersion>
<snapshotVersion>
<extension>pom</extension>
<value>2.1-20110928.112713-14</value>
<updated>20110928112713</updated>
</snapshotVersion>
<snapshotVersion>
<extension>jar</extension>
<value>2.1-20110924.121415-13</value>
<updated>20110924121415</updated>
</snapshotVersion>
<snapshotVersion>
<extension>pom</extension>
<value>2.1-20110924.121415-13</value>
<updated>20110924121415</updated>
</snapshotVersion>
...
</snapshotVersions>
</versioning>
</metadata>

/metadata/versioning/snapshot要素には、test-artifact-2.1-SNAPSHOTでスナップショット・アーティファクトを要求したときにフェッチされた最新のスナップショットに関する情報が含まれています。バージョンのタイムスタンプとビルド番号(2.1.-20110928.112713-14など)を参照して、必要な特定のスナップショットを直接要求することもできます。

通常、継続的インテグレーション・ビルドの適切な運用に必要となるのは最新のスナップショットのみです。スナップショットの古いインスタンスを保持しておくと、スナップショット依存性の変更により統合プロセスに障害が発生したことを、継続的インテグレーション・サーバーによって通知されてときのトラブルシューティングに役立ちます。最後の作業ビルド後に、少し古いビルドをプルすると、問題の特定に役立つ場合があります。

クリーンアップ操作を繰り返し行わないと、スナップショット・インスタンスがプロジェクトの存続期間中に急速に累積する場合があります。リポジトリ・マネージャの記憶域要件を管理するには、古いスナップショットを削除します。使用可能な記憶域およびパフォーマンス要件に応じて、保存ポリシーに関するオプションを設定します。

4.6.1.1 保存オプション

アーティファクトのチェックインによってビルドが頻繁にトリガーされる継続的インテグレーション環境では、大量のビルドが実行される可能性があります。これらの各ビルド(少なくとも正常に実行されたビルド)により、アーティファクトがリポジトリに公開されます。これらにより、領域が大量に消費されることになる可能性があるため、管理することが重要です。

Archivaでは、リポジトリ単位ベースで古いスナップショットを自動的にクリーンアップする次の2つの異なるオプションが提供されています。

- Repository Purge by Number of Days Older
Archivaは、指定した日数よりも古いスナップショットを自動的に削除します。Archivaは、最新のスナップショットを、その古さに関係なく常に保持します。

- Repository Purge by Retention Count
この方法を使用するには、purge-by-days-older値を0に設定する必要があります。Archivaは、この値までの最新のスナップショット・インスタンスのみを保持します。このカウントを超えた古いインスタンスは削除されます。

4.6.1.2 リリース済スナップショットの削除

対応するバージョンがリリースされると、そのバージョンのスナップショットは不要になります。領域を節約できるだけでなく、依存性参照を最新の状態にすることもできます。

このスナップショットを参照する既存の継続的インテグレーション・ビルドは、依存性がリポジトリ・マネージャから削除されると、依存性が欠落していることを示すメッセージが表示されて失敗します。このエラーにより、依存性参照が失効していることを認識することができ、問題を修正するよう促されます。

4.6.2 高度なユーザー管理

Archivaでは、ユーザー管理インフラストラクチャにApache Redbackを使用します。Archivaの認証およびロール管理システムを組織の既存のユーザー管理システムとともに使用するには、Redbackを使用して追加構成を行う必要があります。RedbackによるLDAPおよびその他の認証システムのサポートは限定されています。

次の場所で詳細を参照できます。

http://archiva.apache.org/redback/

4.6.3 Archivaのバックアップ

Archivaファイル・ストアおよび構成をバックアップするメカニズムを提供して、ファイル・システムの障害または破損の発生時にリストアできるようにする必要があります。

バックアップ・ソリューションの選択肢は、フェイルオーバー方法の影響を受ける場合があります。

4.6.4 Archivaのフェイルオーバー

Archivaでは、フェイルオーバー・ソリューションを提供しませんが、最新状態を維持するフェイルオーバー・システムを保守することが重要です。必要に応じて、プライマリ・システムと同期される個別のファイル・システムを使用して同一構成のバックアップ・システムを設定したり、同じ共有ファイル・システムを使用するように両方のシステムを構成することができます。

詳細は、次のArchivaページを参照してください。

https://cwiki.apache.org/ARCHIVA/high-availability-archiva.html

5 ビルド自動化と依存性管理のためのMavenのインストールおよび構成

Mavenは、コンパイル、パッケージ化、アーティファクト管理などのプロジェクト・ビルド・タスクの中心となるビルド管理ツールです。MavenはXMLベースの厳密なルール・セットを使用して、柔軟性を保持しながら整合性を促進します。Java中心の継続的インテグレーション・システムのほとんどがMavenと適切に統合されるため、基盤となるビルド・システムとして適切な選択といえます。この章では、Mavenのインストールと構成方法について説明します。

この章の構成は、次のとおりです。

- 5.1項「Maven配布の設定」

- 5.2項「Maven設定のカスタマイズ」

- 5.3項「Mavenリポジトリ・マネージャへの移入」

5.1 Maven配布の設定

Maven 3.0.4の配布はOracle Fusion Middlewareに含まれています。Oracle WebLogic Serverをインストールした後、Oracleホームの次の場所でMavenを見つけることができます。

ORACLE_HOME/oracle_common/modules/org.apache.maven_3.0.4

これは、Maven 3.0.4標準リリースの変更なしのコピーです。

Maven Webサイトから各自でMavenコピーをダウンロードして、インストールすることもできます。

http://maven.apache.org

Oracle Fusion Middlewareは、Maven 3.0.4以降をサポートしています。

インストール後、オペレーティング・システムのPATH環境変数にMavenを次のように追加します。

- UNIXの場合:
シェル起動スクリプト、.profileまたは.bash_profileを更新して、パスを更新する必要があります。

たとえば、Oracle WebLogic Serverを/u01/fmwhomeにインストールしてbashシェルを使用している場合、PATH環境変数に次の内容を追加する必要があります。

export M2_HOME=/u01/fmwhome/oracle_common/modules/org.apache.maven_3.0.4
export PATH=${M2_HOME}/bin:$PATH

JAVA_HOME環境変数がJDKインストールを指すように設定する必要もあります。次に例を示します。

export JAVA_HOME=/u01/jdk1.7.0_21

- Windowsの場合:
PATH環境変数を編集し、PATH環境変数の先頭にMavenへの正しいパスを追加します。

たとえば、c:\fmwhomeにWebLogic Serverをインストールしてある場合は、次のように追加する必要があります。

C:\fmwhome\oracle_common\modules\org.apache.maven_3.0.4\bin

また、JDKインストールを指し示すようにJAVA_HOME環境変数を設定する必要もあり、たとえば、export JAVA_HOME=/u01/jdk1.7.0_21のように設定します。

5.2 Maven設定のカスタマイズ

次のような場合は、Maven設定ファイルを作成する必要があります。

- ファイアウォールまたはプロキシ・サーバーの背後で作業している場合

- 組織で専用の内部Mavenリポジトリ・マネージャを使用している場合

Maven設定ファイルはsettings.xmlと呼ばれ、通常はホーム・ディレクトリ内の.m2ディレクトリに保持されます。Mavenが他の場所を指し示すようにする場合は、Mavenマニュアルを参照してください。

Oracle WebLogic Serverインストールの一環として、またはMaven Webサイトからダウンロードして、初めてMavenのインストールが完了したときには、設定ファイルはまだありません。

- UNIXの場合:
ユーザー名がbobの場合、ディレクトリ・パスは次のようになります。

/home/bob/.m2/settings.xml

- Windowsの場合:
ユーザー名がbobの場合、ディレクトリ・パスは次のようになります。

C:\Users\bob\.m2\settings.xml

Maven設定ファイルの例を次に示します。

<settings>
<proxies>
<proxy>
<active>true</active>
<protocol>http</protocol>
<host>proxy.mycompany.com</host>
<port>8080</port>
<nonProxyHosts>mycompany.com</nonProxyHosts>
</proxy>
</proxies>
<servers>
<server>
<id>maven.mycompany.com</id>
<username>me@mycompany.com</username>
<password>{COQLCE6DU6GtcS5P=}</password>
</server>
</servers>
<mirrors>
<mirror>
<id>archiva</id>
<name>Internal Archiva Mirror of Central</name>
<url>http://archiva.mycompany.com/repositories/internal</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>

</settings>

この例では、使用する可能性がある3つの共通構成の設定を示しています。

- Proxyを使用すると、インターネット上のMavenリポジトリにアクセスするために必要なHTTPプロキシ・サーバーについて、Mavenと通信できます。

- Serversを使用すると、Mavenリポジトリの資格証明についてMavenと通信できるため、リポジトリにアクセスするたびにこれらを入力する必要がなくなります。

- Mirrorsは、Mavenの中央リポジトリに対して直接アクセスを試みるかわりに、内部のMavenリポジトリ・マネージャをMavenの中央リポジトリのミラー(キャッシュ)として使用するようにMavenに通知します。

これらの用語に精通していない場合は、第1章の概要を参照してください。使用可能なMaven設定の詳細は、次の場所にあるMavenマニュアルを参照してください。

http://maven.apache.org/settings.html

5.3 Mavenリポジトリ・マネージャへの移入

たとえば第4章でArchivaを設定したように、Mavenリポジトリ・マネージャの構成が完了した後で、Oracleアーティファクトを移入したい場合があります。

そのために、Maven同期プラグインが提供されており、このプラグインを使用してOracleホームからローカルまたは共有Mavenリポジトリに移入できます。Fusion Middleware 12c製品をインストールしている場合、同期プラグインで検出できるように、Maven原型、プラグインおよびPOMが製品とともにインストールされます。

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

- Maven同期プラグインの概要

- Oracle Maven同期プラグインのインストール

- Oracle Maven同期プラグインの実行

- アーティファクトの置換に関する予備知識

- Mavenリポジトリへの移入

- pushゴールの実行

- パッチ適用の予備知識

- 原型カタログに関する考慮事項

- settings.xmlの例

- 単一アーティファクトのデプロイ

5.3.1 Maven同期プラグインの概要

Oracle Fusion Middleware 12cにはMaven同期プラグインが用意されており、これによってリポジトリの設定プロセスが簡略化され、特定の環境にインストールされるパッチを認識しておく必要性が完全に排除されます。このプラグインを使用すると、指定のOracleホームからMavenリポジトリに移入できます。Oracleホームにパッチを適用した後、このプラグインを実行して、MavenリポジトリがOracleホームと一致するようにする必要があります。これにより、その特定の環境のすべてのアーティファクトについて、ビルドで正しいバージョンを使用していることが確実になります。

Oracle Maven同期プラグインは、Oracle WebLogic Server、Oracle CoherenceおよびOracle JDeveloperのインストールに含まれています。プラグインを使用するには、Oracleホームの場所とMavenリポジトリの場所を指定する必要があります。Mavenリポジトリは、ファイル・システムのパスまたはURLのいずれかを使用して指定できます。プラグインはOracleホーム内のすべてのMavenアーティファクトを調べて、すべてのアーティファクトが指定したMavenリポジトリにインストールされていること、およびバージョンが完全に一致していることを確認します。これは、バージョン番号とファイルがバイナリ・レベルで完全に同一であることを意味し、すべてのパッチ適用済ファイルがMavenリポジトリ内に正確に反映されます。

12cのOracleホームにはmavenディレクトリがあり、ここには様々なビルド操作を実行するための、Oracle提供アーティファクト用のMavenプロジェクト・オブジェクト・モデル(POM)、プロジェクトを作成するための原型、およびOracle提供のMavenプラグインが含まれています。

5.3.2 Oracle Maven同期プラグインのインストール

Oracle Maven同期プラグインの使用を開始する前に、これをMavenリポジトリにインストールする必要があります。コンピュータ上のローカル・リポジトリにインストールするか、共有内部リポジトリがある場合は、ここにデプロイします。

プラグインはOracle WebLogic Server 12cホームにあり、2つのファイルで構成されています。

- プラグインについて記述するMavenプロジェクト・オブジェクト・モデル(POM)ファイル。次の場所にあります。

ORACLE_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.2/oracle-maven-sync.12.1.2.pom

- プラグインを含むJARファイル。次の場所にあります。

ORACLE_HOME/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.2/oracle-maven-sync.12.1.2.jar

ローカルMavenリポジトリにプラグインをインストールするには、ORACLE_COMMON/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.2ディレクトリから次のコマンドを実行します。

mvn install:install-file -DpomFile=oracle-maven-sync.12.1.2.pom -Dfile=oracle-maven-sync.12.1.2.jar

最も簡単な方法としては、共有内部リポジトリにプラグインをデプロイし、Mavenリポジトリ・マネージャによって提供されるWebユーザー・インタフェースを使用して、リポジトリにJARファイルをアップロードします。

代替方法としては、デプロイ・プラグインを使用しますが、これは、ORACLE_COMMON/oracle_common/plugins/maven/com/oracle/maven/oracle-maven-sync/12.1.2ディレクトリから次のようなコマンドを使用することで実行できます。

mvn deploy:deploy-file -DpomFile=oracle-maven-sync-12.1.2.pom -Dfile=oracle-maven-sync-12.1.2.jar
-Durl=http://servername/archiva/repositories/internal -DrepositoryId=internal

このように、デプロイ・プラグインを使用するには、Mavenのsettings.xmlファイルでリポジトリを定義し、さらに匿名の公開が許可されていない場合には、資格証明を定義する必要があります。

このコマンドの詳細は、次の場所にあるMavenマニュアルを参照してください。

http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html

5.3.3 Oracle Maven同期プラグインの実行

Oracle Maven同期プラグインでは、次の2つのMavenゴールがサポートされています。

- help: ヘルプ情報を出力します。

- push: リポジトリへの移入に使用されます。

次のコマンドでhelpゴールを実行できます。

mvn com.oracle.maven:oracle-maven-sync:help

helpゴールの出力は、次のとおりです。

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building odm 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- oracle-maven-sync:12.1.2:help (default-cli) @ odm ---
[INFO] ------------------------------------------------------------------------
[INFO] ORACLE MAVEN SYNCHRONIZATION PLUGIN - HELP
[INFO] ------------------------------------------------------------------------
[INFO] The following goals are available:
[INFO]
[INFO] help           prints this help
[INFO]
[INFO] push           Install to the local repository and optionally deploy
[INFO]                to a remote repository from the specified oracle home
[INFO]
[INFO]                The plugin will use your current Maven settings to
[INFO]                determine the path to the local repository and,
[INFO]                optionally, a remote deployment repository.  For
[INFO]                details on how to configure Maven's repository
[INFO]                settings, see the Maven settings reference:
[INFO]                http://maven.apache.org/settings.html
[INFO]    parameters:
[INFO]          oracle-maven-sync.oracleHome
[INFO]                - This is the path to the Oracle Home
[INFO]          oracle-maven-sync.testOnly
[INFO]                - Must be set to 'false' or no action will be taken
[INFO]                  Defaults to 'true'
[INFO]          oracle-maven-sync.failOnError
[INFO]                - If set to 'true' the plugin will stop and return an
[INFO]                  error immediately upon the first failure to deploy
[INFO]                  an artifact.  Otherwise, the plugin will log the
[INFO]                  error and attempt to complete deployment of all
[INFO]                  other artifacts.
[INFO]                  Defaults to 'false'
[INFO]          oracle-maven-sync.serverId [OPTIONAL]
[INFO]                - This is the ID of the server (repository) in
[INFO]                  your settings.xml file - where you have
[INFO]                  specified the remote Maven repository and its
[INFO]                  authentication information. The plugin will
[INFO]                  only install to the local repository if this
[INFO]                  parameter is not set.
[INFO]
[INFO]
[INFO] You can specify the parameters on the command line like this:
[INFO]   -Doracle-maven-sync.serverId=archiva-internal
[INFO]   -Doracle-maven-sync.testOnly=false
[INFO]   -Doracle-maven-sync.failOnError=false
[INFO]
[INFO] To override the localRepository target used by the plugin, you
[INFO] can specify the following option on the command-line:
[INFO]   -Dmaven.local.repo=/alternate/path/to/repository
[INFO]
[INFO] To supply an alternate settings.xml for purposes of this operation,
[INFO] use the --settings option.  For example:
[INFO]   mvn --settings /alternate/path/settings.xml ...
[INFO]
[INFO] ...or in your POM like this:
[INFO]   <plugin>
[INFO]     <groupId>com.oracle.maven</groupId>
[INFO]     <artifactId>oracle-maven-sync</artifactId>
[INFO]     <version>12.1.2</version>
[INFO]     <configuration>
[INFO]       <oracleHome>/home/mark/Oracle/Middleware</oracleHome>
[INFO]       <failOnError>false</failOnError>
[INFO]     </configuration>
[INFO]   </plugin>
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.689s
[INFO] Finished at: Day Month Year Time Year
[INFO] Final Memory: 3M/119M
[INFO] ------------------------------------------------------------------------

この出力には、プラグインのpushゴールで使用可能なパラメータが示されています。表5-1に、パラメータを示します。

表5-1 pushゴールのパラメータと説明

パラメータ

説明

serverId

Mavenのsettings.xmlファイルに含まれるサーバー・エントリへのポインタ。これは、リモート・リポジトリにデプロイする場合にのみ必要です。settings.xmlでは、URL、ユーザー名、パスワードなどのリモート・アーティファクト・リポジトリのデプロイメント情報を提供する必要があります。

oracleHome

Mavenリポジトリへの移入元にするOracleホームへのパス。

testingOnly

これは、プラグインでリポジトリへのアーティファクトの公開を試行するかどうかを制御します。

これをデフォルト値のtrueにテストすると、pushゴールによってすべてのPOMファイルが検索され、falseに設定されている場合に実行される内容の詳細が出力されます。ただし、アーティファクトは公開されず、システムも変更されません。

failOnError

このプロパティをfalseに設定している場合、プラグインでリソースの処理に失敗しても、すべてのリソースの処理が続行されます。失敗は警告としてログに記録されますが、処理は正常に完了します。

このプロパティをtrueに設定した場合、最初の問題が発生するとすぐにプラグインがエラーで終了します。これがデフォルトです。

5.3.4 アーティファクトの置換に関する予備知識

一部のMavenリポジトリ・マネージャには、リポジトリ内の既存アーティファクトの置換を可能にするかどうかを制御する設定があります。Mavenリポジトリ・マネージャにこのような設定がある場合は、Oracle Maven同期プラグインでリポジトリ内のアーティファクトを更新できるように、正しく設定されていることを確認する必要があります。この画面は、管理メニューで「Repositories」を選択してアクセスします。次に、「Edit」をクリックして、必要なリポジトリの設定を変更します。

Archivaを使用している場合は、「Managed Repository」設定の「Block Re-deployment of Released Artifacts」オプションの選択を解除する必要があります。

その他のMavenリポジトリ・マネージャにも同様の設定があります。別のツールを使用している場合は、そのツールのマニュアルを参照して、この設定の変更方法を確認してください。

5.3.5 Mavenリポジトリへの移入

リポジトリに移入するには、pushゴールを使用する必要があります。表5-1に示すパラメータをコマンドラインまたはプロジェクト・オブジェクト・モデル・ファイルで指定します。

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

- ローカル・リポジトリへの移入

- リモート・リポジトリへの移入

5.3.5.1 ローカル・リポジトリへの移入

ローカル・リポジトリに移入する場合は、oracleHomeおよびtestingOnly=falseを指定するだけです。

次に例を示します。

mvn com.oracle.maven:oracle-maven-sync:push
-DoracleHome=/path/to/oracleHome
--Doracle-maven-sync.testingOnly=false

settings.xmlファイルのlocalRepository要素は、ローカルMavenリポジトリの場所を示します。settings.xmlからlocalRepository要素を取り除くと、デフォルトの場所は${HOME}/.m2/repositoryディレクトリ内になります。

localRepository値をオーバーライドする場合は、Mavenオプションとしてコマンドラインにオーバーライドの場所を指定する必要があります。

次に例を示します。

mvn com.oracle.maven:oracle-maven-sync:push
-Doracle-maven-sync.oracleHome=/path/to/oracleHome
-Dmaven.repo.local=/alternate/path

プロジェクト・オブジェクト・モデル・ファイルにパラメータを指定するには、プロジェクト・オブジェクト・モデル・ファイルに次のようなプラグイン・エントリを追加する必要があります。

<plugin>
<groupId>com.oracle.maven</groupId>
<artifactId>oracle-maven-sync</artifactId>
<version>12.1.2</version>
<configuration>
<oracleHome>/path/to/oracleHome</oracleHome>
<testOnly>false</testOnly>
</configuration>
</plugin>

プラグインを追加した後、コマンドラインで次のコマンドを実行してMavenを実行します。

mvn com.oracle.maven:oracle-maven-sync:push

5.3.5.2 リモート・リポジトリへの移入

リモート・リポジトリに移入する場合は、コマンドライン・インタフェースまたはプラグイン構成でserverIdおよびoracleHomeを指定する必要があります。また、プラグインに指定したserverIdと一致するようにsettings.xmlのリポジトリ構成を指定する必要があります。デプロイメントに認証が必要な場合は、Mavenのsettings.xmlにもサーバー・エントリを追加する必要があります。

次に例を示します。

mvn com.oracle.maven:oracle-maven-sync:push
-Doracle-maven-sync.oracleHome=/path/to/oracleHome
-Doracle-maven-sync.serverId=internal

これに対応する認証付きのMaven settings.xmlは、次のようになります。

...
<profiles>
<profile>
<id>default</id>
<repositories>
<repository>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<id>internal</id>
<name>Team Internal Repository</name>
<url>http://some.host/maven/repo/internal</url>
<layout>default</layout>
</repository>
</repositories>
</profile>
</profiles>
...
<server>
<id>internal</id>
<username>deployer</username>
<password>welcome1</password>
</server>
...
<activeProfiles>
<activeProfile>default</activeProfile>
</activeProfiles>

プロファイルにターゲット・リポジトリを定義し、前述の例に示すactiveProfilesタグを使用して、そのプロファイルをアクティブ化する必要があります。

注意:

serverセクションに、暗号化されたパスワードを指定する必要があります。サーバー・パスワードの暗号化方法については、次を参照してください。

http://maven.apache.org/guides/mini/guide-encryption.html#How_to_encrypt_server_passwords

プロジェクト・オブジェクト・モデル・ファイルにパラメータを指定するには、プロジェクト・オブジェクト・モデル・ファイルに次のようなプラグイン・エントリを追加する必要があります。

<plugin>
<groupId>com.oracle.maven</groupId>
<artifactId>oracle-maven-sync</artifactId>
<version>12.1.2</version>
<configuration>
<serverId>internal</serverId>
<oracleHome>/path/to/oracleHome</oracleHome>
<testOnly>false</testOnly>
</configuration>
</plugin>

プラグインを追加した後、コマンドラインで次のコマンドを実行してMavenを実行します。

mvn com.oracle.maven:oracle-maven-sync:push

5.3.6 pushゴールの実行

pushゴールを実行すると、次の処理が行われます。

- 指定されたOracleホームを確認し、そのOracleホームに含まれるすべてのMavenアーティファクトの一覧を作成します。これは、ORACLE_HOME/oracle_common/plugins/maven依存性ディレクトリおよびそのサブディレクト内でプロジェクト・オブジェクト・モデル・ファイルを再帰的に検索し、ORACLE_HOMEに存在するPRODUCT_HOMEごとにORACLE_HOME/PRODUCT_HOME/plugins/mavenディレクトリおよびそのサブディレクトリ内を再帰的に検索することで実行します。

- 各プロジェクト・オブジェクト・モデル・ファイルで参照されているJARファイルがOracleホームで使用可能かどうかを確認します。

- JARファイルのSHA1チェックサムを計算します。

- 指定されたリポジトリに対するJARファイル、プロジェクト・オブジェクト・モデル・ファイルおよびSHA1ファイルの公開を試行します。

次のタイプのMavenアーティファクトがリポジトリにインストールされます。

- Oracleによって提供されている次のようなMavenの依存性

- クライアントAPIクラス

- appcやwlstなどのコンパイル、パッケージ化およびデプロイメント・ユーティリティ

- アプリケーションへの組込みが必要なコンポーネントJAR

- t3およびJAX-WSクライアント・ランタイムなどのクライアント側のランタイム・クラス

- コンパイル、パッケージ化およびデプロイメントを処理するOracle提供のMavenプラグイン

- プロジェクト・テンプレートを提供するOracle提供のMaven原型

5.3.7 パッチ適用の予備知識

パッチ適用は、システムを軽微な変更で更新する操作で、通常はソフトウェアが本番環境に移された後に認識された不具合を修正します。Oracle Fusion Middlewareでは、Oracleパッチ(OPatch)を使用して、Oracleホームにインストールされているソフトウェアへのパッチ適用を管理します。Oracleパッチを使用してパッチを適用しても、インストールされているソフトウェアのバージョン番号は変更されません。

Mavenでは、リリース済のソフトウェアが変更されないことを前提としたパッチ適用に対し、様々なアプローチを使用します。パッチが必要な場合、新しいバージョン番号を持つ新しいバージョンのアーティファクトが作成され、パッチとして配布されます。

Mavenを使用してOracle Fusion Middleware環境でアプリケーションを開発する場合には、この違いによって問題が発生します。Oracle Fusion Middleware 12.1.2では、この問題に対応するためのメカニズムを提供しています。

5.3.7.1 パッチ適用に対するOracleのアプローチ

Oracle Fusion Middleware (12.1.2など)を本番環境にリリースした後で問題が見つかった場合、この問題を修正するための個別パッチが作成されます。たとえば、12.1.2と12.1.3などの2つのリリースの間にこのようなパッチが多くリリースされます。これらのパッチをすべて適用する、またはこれらのパッチのいずれも適用しないなど、多数のパッチの組合せを適用できます。

このアプローチでは高い柔軟性が提供されるため、必要なパッチのみを適用し、残りは無視することができます。ただし、Mavenを使用している場合には、問題が発生する可能性があります。ビルド・システムで使用しているアーティファクトのバージョンがターゲット環境で使用されているバージョンと正確に同じである(パッチ適用済の可能性もある)ことを確認してください。

テスト、QA、SIT、本番などの多数の環境が存在する場合には複雑さが増し、それぞれに異なるバージョン(またはパッチ)がインストールされる可能性が高くなります。

5.3.7.2 環境ごとに1つのMavenリポジトリを保持

このような状況では、ターゲットにする環境ごとに1つのMavenリポジトリを設定することをお薦めします。たとえば、Mavenテスト・リポジトリには、テスト環境にインストールされているバージョンおよびパッチと一致するアーティファクトを格納し、Maven QAリポジトリには、QA環境にインストールされているバージョンおよびパッチと一致するアーティファクトを格納するというように設定します。

5.3.7.3 パッチ適用後のOracle Maven同期プラグインのpushゴールの実行

Oracleホームにパッチを適用した後、このプラグインを実行して、MavenリポジトリがOracleホームと一致するようにする必要があります。これにより、その特定の環境のすべてのアーティファクトについて、ビルドで正しいバージョンを使用していることになります。

5.3.8 原型カタログに関する考慮事項

Oracle Maven同期プラグインのpushゴールを実行することによって、Mavenリポジトリに新しいMaven原型がインストールされる場合があります。原型の索引を再ビルドするためにコマンドの実行が必要になることがあります。一部のMavenリポジトリ・マネージャではこれを自動的に行います。

原型カタログを再ビルドするには、次のようなコマンドを実行します。

mvn archetype:crawl -Dcatalog=$HOME/.m2/archetype-catalog.xml

5.3.9 settings.xmlの例

このsettings.xmlの例には、このマニュアルに記載されている継続的インテグレーション・システムの残りの部分とMavenとを統合するためのテンプレートが示されています。第4章および第12章で説明している、中心となるArchivaリポジトリのインタラクションとHudsonの継続的インテグレーション・サーバーの統合をサポートする構成が示されています。各自のシステムの値と一致するように、URL、パスワードなどの値を変更する必要があります。

<settings>
<profiles>
<profile>
<id>default</id>
<repositories>
<repository>
<id>dev-group</id>
<name>Dev Group</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/dev-group</url>
<layout>default</layout>
</repository>
<repository>
<id>dev</id>
<name>Dev</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/dev</url>
<layout>default</layout>
</repository>
<repository>
<id>prod-group</id>
<name>Prod Group</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/prod-group</url>
<layout>default</layout>
</repository>
<repository>
<id>prod</id>
<name>Prod</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/prod</url>
<layout>default</layout>
</repository>
<repository>
<id>qa-group</id>
<name>QA Group</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/qa-group</url>
<layout>default</layout>
</repository>
<repository>
<id>qa</id>
<name>QA</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/qa</url>
<layout>default</layout>
</repository>
<repository>
<id>test-group</id>
<name>Test Group</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/test-group</url>
<layout>default</layout>
</repository>
<repository>
<id>test</id>
<name>Test</name>
<releases>
<enabled>true</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/test</url>
<layout>default</layout>
</repository>
<repository>
<id>archiva-snapshots</id>
<name>Archiva Snapshots</name>
<releases>
<enabled>false</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://SERVER:PORT/archiva/repository/snapshots</url>
<layout>default</layout>
</repository>
</repositories>
</profile>
</profiles>
<servers>
<server>
<id>dev</id>
<username>hudson</username>
<password>PASSWORD</password>
</server>
<server>
<id>dev-group</id>
<username>hudson</username>
<password>PASSWORD</password>
</server>
<server>
<id>archiva-snapshots</id>
<username>hudson</username>
<password>PASSWORD</password>
</server>
</servers>
<mirrors>
<mirror>
<id>dev-mirror</id>
<name>All else</name>
<url>http://SERVER:PORT/archiva/repository/dev-group</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
<activeProfiles>
<activeProfile>default</activeProfile>
</activeProfiles>
</settings>

5.3.10 単一アーティファクトのデプロイ

Mavenのデプロイ・プラグインを使用して、リモート・アーティファクト・リポジトリにアーティファクトおよびプロジェクト・オブジェクト・モデルをデプロイすることもできます。

たとえば、settings.xmlファイルの例にある定義に従ってarchiva-releasesリポジトリにデプロイするには、次のコマンドを実行します。

mvn deploy:deploy-file
-Dfile=/path/to/oracle-maven-sync-12.1.2.jar
-DrepositoryId=archiva-releases
-DpomFile=/path/to/oracle-maven-sync-12.1.2.pom
-Durl=http://server:port/archiva/repository/internal

6 継続的インテグレーションのためのHudsonのインストールおよび構成

Hudsonは、一般に使用されている継続的インテグレーション・サーバー製品です。これを使用すると、ビルド・ジョブを定義し、これらのジョブの実行を管理できます。必要に応じて、ビルド・サーバーのファームまで拡張できます。

この章では、Hudsonをインストールしてビルド・プロセスを自動化するように構成する方法、およびMavenを使用してHudsonを統合する方法について説明します。

この章の構成は、次のとおりです。

- 6.1項「Hudsonをインストールおよび構成するための前提条件」

- 6.2項「Hudsonのダウンロード」

- 6.3項「Hudsonのインストール」

- 6.4項「HTTPポートの構成」

- 6.5項「Hudsonの開始」

- 6.6項「起動後のMavenの構成」

- 6.7項「追加情報」

6.1 Hudsonをインストールおよび構成するための前提条件

インストールを開始する前に、継続的インテグレーション・システムの次のコンポーネントが構成されていることを確認します。

- 第3章に示すように、Subversionサーバーが構成され、実行されていること。

- 第4章に示すようにArchivaが構成され、実行されていること。これは、Oracle Fusion Middleware製品がOracleホームにインストールされ、Oracle Maven同期化プラグインを実行してArchivaに移入していることを意味します。

- JDK 1.6以降がHudsonホストにインストールされていること。

- Maven 3がHudsonホストにインストールされていること。

6.2 Hudsonのダウンロード

Hudsonの最新の製品バージョンは、次の場所から直接ダウンロードできます。

http://hudson-ci.org/

Hudsonは2つの異なるバージョンに分かれています。

- スタンドアロンとして実行するか、または既存のアプリケーション・サーバー・インストールに追加できるWARファイル。

- 特定のオペレーティング・システム向けにコンパイルされているLinux RPM。RPMおよび必要な依存性をインストールするために、適切なリポジトリ形式のパッケージ管理サポートを利用できます。

このマニュアルでは、Oracle LinuxおよびWindowsのインストールについて重点的に説明します。他のオペレーティング・システムの詳細は、これらと異なる場合があります。各タイプのインストール手順については、http://wiki.hudson-ci.org/display/HUDSON/Installing+Hudsonを参照してください。

6.3 Hudsonのインストール

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

- LinuxへのHudsonのインストール

- WindowsへのHudsonのインストール

6.3.1 LinuxへのHudsonのインストール

YUMをサポートするLinuxコンピュータで、コマンドラインから次のコマンドを実行します。

sudo wget -O /etc/yum.repos.d/hudson.repo http://hudson-ci.org/redhat/hudson.repo
sudo yum check-update
sudo yum install hudson

これにより、Hudsonがデーモンとしてインストールされ、Hudsonユーザーが作成されます。このユーザーは、ビルド・ジョブ関連アクティビティを実行するために、サーバーによって使用されます。

6.3.2 WindowsへのHudsonのインストール

Hudson WAR配布をダウンロードし、コマンドラインから次のコマンドを実行して、スタンドアロン・モードでこれを開始します。

java -jar hudson-2.2.1.war

Hudsonが開始したら、次の手順を実行します。

1. 次のURLをWebブラウザで開きます。

http://localhost:8080

2. 「Manage Hudson」→「Install as Windows Service」の順に移動します。これで、HudsonをスタンドアロンWindowsサービスとして構成できます。
手順については、http://wiki.hudson-ci.org/display/HUDSON/Installing+Hudson+as+a+Windows+serviceを参照してください。

6.4 HTTPポートの構成

アーティファクト・リポジトリおよび継続的インテグレーション・サーバーに単一ホストを使用している場合、Hudsonが使用するHTTPポートを変更する必要があります。

- Linuxの場合
この値は、/etc/sysconfig/hudsonディレクトリのHUDSON_PORTに存在しています。

- Windowsの場合
この値は、c:\ciroot\hudson\etc\sysconfig\hudsonディレクトリに存在しています。

6.5 Hudsonの開始

Hudsonを開始するには、次の手順を実行します。

- Linuxの場合
Hudsonをサービスとしてインストールしている場合は、次のコマンドを実行してアプリケーションを開始できます。

/etc/init.d/hudson start

次のディレクトリのログを確認すると、Linuxで起動を監視できます。

/var/log/hudson/hudson.log

ログを監視するには、次のコマンドを実行します。

tail -f /var/log/hudson/hudson.log

- Windowsの場合
Windowsで通常サービスとしてHudsonを開始します。

1. 「コントロール パネル」に移動します。

2. 「管理ツール」→「サービス」の順に移動します。

3. Hudsonサービスを選択し、「開始」をクリックします。

Hudsonログは次の場所にあります。

HUDSON_HOME/logs

6.6 起動後のMavenの構成

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

- 最初の起動時

- JDKの構成

- Mavenホームの指定

- Hudsonで使用するためのMavenの設定

- Hudsonプラグインのインストール

- リポジトリの統合

- Subversionの監視

6.6.1 最初の起動時

最初にHudsonを起動したときには、ホーム・ページに移動してインストールを完了します。

1. ブラウザを開き、http://localhost:8080に移動します(インストール中にポートを変更した場合は、これを変更します)。

2. 表示されたプラグインのリストを下にスクロールして、「Subversion」、「Maven 3」および「Maven 3 SNAPSHOT Monitor」オプションを探し、これらのオプションを選択します。

3. 一番下までスクロールし、「Install」をクリックします。

4. 「Finish」をクリックし、Hudsonホーム・ページに移動します。

この項の構成の残りの部分は、Hudsonホーム・ページから続行します。

6.6.2 JDKの構成

ダイレクトJavaビルド構成に使用する予定のJDKを構成する必要があります。構成するには、次の手順を実行します。

1. Hudsonにログインします。

http://HOSTNAME:HUDSON_PORT

2. 「Manage Hudson」→「Configure System」の順に移動します。

3. 「Configure System」画面で、「JDK」セクションまで下にスクロールし、「Add JDK」をクリックして、オプション「Install automatically」の選択を解除してから、jdk1.7.0などの名前を入力し、インストールされているJDKの完全パスを追加します。
たとえば、/ciroot/product_binaries/jdk1.7.0_21などです。

4. ページの一番下までスクロールし、「Save」をクリックします。

6.6.3 Mavenホームの指定

Maven 3の場所を指定して、Mavenの場所をHudsonが認識できるようにする必要があります。これを行うには、次の手順を実行します。

1. Hudsonにログインします。

http://HOSTNAME:HUDSON_PORT

2. 「Manage Hudson」→「Configure System」の順に移動します。

3. 「Configure System」画面で、セクション「Maven 3」まで下にスクロールします。

4. 「Add Maven」をクリックした後、次の図に示すように、オプション「Install automatically」の選択を解除し、名前とMavenインストールへの完全パスを入力します。

5. ページの一番下までスクロールし、「Save」をクリックします。

6.6.4 Hudsonで使用するためのMavenの設定

HudsonからMaven設定を利用するには、settings.xmlの内容をHudsonのグローバルMaven構成の設定オブジェクトに組み込みます。

1. Hudsonにログインします。

http://HOSTNAME:HUDSON_PORT

2. 「Manage Hudson」→「Maven 3 Configuration」の順に移動します。

3. 「Add」をクリックします。

4. 「Type」で「SETTINGS」を選択します。

5. 名前および説明(オプション)を入力します。

6. 第5章で構成したファイル・システムでsettings.xmlを検索し、内容をページの一番下にある大きいテキスト・フィールドにコピーします。これは、/$HOME/.m2/settings.xmlディレクトリにあります。

7. 「Save」をクリックします。

注意:

オラクル社では、settings.xmlにあるlocalhostのURL参照を完全修飾ドメイン名またはIPアドレスで置き換えることをお薦めしていますが、これは、Hudsonビルドが最終的には非ローカル・ビルド・ホストで発生するためです。

6.6.5 Hudsonプラグインのインストール

Hudsonジョブでは、ジョブ固有の環境変数のカスタマイズが必要になる場合があります。デフォルトでは、Hudsonはこれをサポートしていないため、追加のプラグインをインストールする必要があります。プラグインをインストールするには、次の手順を実行します。

1. Hudsonにログインします。

http://HOSTNAME:HUDSON_PORT

2. 「Manage Hudson」→「Manage Plugins」の順に移動します。

3. 「Available」を選択します。

4. 「Hudson Setenv Plugin」を選択します。

5. 「Install」をクリックします。

6. インストールの完了後、Hudsonの再起動オプションを使用してプラグインを有効にします。

6.6.6 リポジトリの統合

変更がチェックインされたときに自動ビルドを構成するには、アーティファクト・リポジトリのSNAPSHOTデプロイメント変更を監視するように、Hudsonを構成する必要があります。このような変更は、変更されたアーティファクトに対する依存性を持つために影響を受けるコンポーネントのビルドをトリガーします。アーティファクト・リポジトリを監視するようにHudsonを構成するには、次の手順を実行します。

1. Hudsonにログインします。

http://HOSTNAME:HUDSON_PORT

2. 「Manage Hudson」→「System Configuration」の順に移動します。

3. 「System Configuration」のメイン・システム構成パネルで、「Maven 3 SNAPSHOT Monitor」を選択します。継続的インテグレーション・サーバーがリポジトリにアクセスできるように、Archiva構成手順で、継続的インテグレーション固有のユーザーを作成しておく必要があります。Mavenリポジトリへのパスを入力します。

4. 継続的インテグレーション・ユーザーの「User」および「Password」を設定します。

6.6.7 Subversionの監視

アーティファクト・リポジトリの依存性更新を監視する以外に、継続的インテグレーション・サーバーではソース・コントロール・システムの更新を常に確認し、それに応じてプロジェクト・ビルドをトリガーする必要があります。リポジトリ監視とは異なり、ソフトウェア構成管理の監視は、ビルド構成ごとに一意に構成する必要があります。新しいビルド構成を作成する場合は、関連プロジェクトのSubversionの場所情報を設定する必要があります。詳細は、12.3項を参照してください。

Subversionのサポートは、基本のHudson配布に同梱されています。その他のソース・コントロール・システムでは、別個のHudsonプラグイン・インストールが必要になる場合があります。

6.7 追加情報

Hudsonの公式マニュアルのプライマリ・ソースは次の場所にあります。

http://wiki.hudson-ci.org/display/HUDSON/Use+Hudson

新規ユーザーの場合は、次の場所でHudsonの導入ガイドを参照できます。

http://wiki.eclipse.org/Hudson-ci/Using_Hudson

7 Mavenのバージョン番号の理解

Maven環境では、バージョン番号の使用を理解することが非常に重要です。よく考えられた計画では、依存性管理ワークロードが大幅に簡素化されます。この章では、Mavenで一般的にバージョン番号がどのように機能するかに関する重要な概念について説明し、Oracle提供のアーティファクトにおけるバージョン番号の使用方法の具体的な詳細、およびOracleアーティファクトを参照する場合のバージョン番号の使用方法についても説明します。

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

- 7.1項「バージョン番号がMavenで機能する仕組み」

- 7.2項「SNAPSHOT修飾子」

- 7.3項「バージョン範囲参照」

- 7.4項「Oracle提供のアーティファクトでのMavenバージョン番号の理解」

7.1 バージョン番号がMavenで機能する仕組み

Mavenのバージョニング・スキームでは、次の標準を使用します。

- MajorVersion

- MinorVersion

- IncrementalVersion

- BuildNumber

- Qualifier

次に例を示します。

- MajorVersion: 1.2.1

- MinorVersion: 2.0

- IncrementalVersion: 1.2-SNAPSHOT

- BuildNumber: 1.4.2-12

- Qualifier: 1.2-beta-2

修飾子があるすべてのバージョンは、修飾子がない同じバージョン(リリース・バージョン)よりも古くなります。

次に例を示します。

1.2-beta-2は1.2よりも古いことになります。

修飾子フィールドが異なる同一バージョンは、基本的な文字列比較を使用して比較されます。

次に例を示します。

1.2-beta-2は1.2-alpha-6よりも新しくなります。

プロジェクト・バージョニング・スキームでMavenバージョニング標準に従わない場合、バージョン比較の際、Mavenではバージョン全体が単純な文字列として解釈されます。Mavenおよびその主要プラグインでは、様々なタスク(最も重要なのはリリース・プロセス)でバージョン比較が使用されます。

非標準のバージョニング・スキームを使用する場合、Mavenのリリースおよびバージョンのプラグイン・ゴールで、想定された結果がもたらされない場合があります。非標準バージョンでは基本的な文字列比較が実行されるため、バージョン比較でバージョンの順序が正しく計算されない場合があります。

たとえば、Mavenではバージョン・リストを次のように配置します。

1.0.1.0
1.0.10.1
1.0.10.2
1.0.9.3

バージョン1.0.9.3は、1.0.10.1および1.0.10.2の前に配置される必要がありますが、予期しない4番目のフィールド(.3)によってMavenではバージョンが文字列として評価されています。

Mavenでのこの影響の例は、Mavenバージョン・プラグインで見つかります。Mavenバージョン・プラグインでは、プロジェクト依存性の現在性を様々な方法でチェックするゴールが提供されます。有用なゴールの1つにversions:dependency-updates-reportがあります。versions:dependency-updates-reportゴールでは、プロジェクトの依存性階層を調査し、より新しいリリースを使用できるのはどのプロジェクトであるかをレポートします。大規模なリリースを調整する場合、このゴールは、依存性構成内の失効した参照を見つけるのに役立ちます。Mavenで新しいリリースが正しく特定されなかった場合、プラグインでも正しくレポートされません。前述の例の順序では、現在の参照が1.0.10.2であった場合、プラグインでは1.0.9.3が新しいリリースとしてレポートされます。

依存性参照でバージョン範囲を使用する予定である場合は、バージョンの解決も非常に重要になります。バージョン変更の詳細は、7.3項を参照してください。

7.2 SNAPSHOT修飾子

Mavenでは、SNAPSHOT修飾子の処理が他の修飾子とは異なります。バージョン番号の後に-SNAPSHOTが続く場合、Mavenでは、関連するMajorVersion、MinorVersionまたはIncrementalVersionの「まだリリースされていない」バージョンとみなされます。

継続的インテグレーション環境では、SNAPSHOTバージョンは、各統合ステップで必要となる再ビルドの量を最小限に抑えながら、統合ビルドを最新の状態に保つという重要な役割を果たします。

SNAPSHOTバージョン参照により、Mavenでは、依存プロジェクト・ビルド時間で最後にデプロイされたSNAPSHOT依存性インスタンスをフェッチできるようになります。SNAPSHOTは常に変わることに注意してください。エージェントがアーティファクトをデプロイするたびに、共有リポジトリで更新されます。SNAPSHOT依存性は、開発者のマシンで再フェッチされるか、またはすべてのビルドで更新されます。これにより、プロジェクト依存性参照構成に対する変更を加えることなく、依存性が最新の変更内容で更新および統合されます。

通常、アーティファクトの特定のバージョンのうち、最後にデプロイされたSNAPSHOTのみがアーティファクト・リポジトリに保持されます。特定のアーティファクトの複数の最新デプロイメントを使用してローリング・アーカイブを保持するようにリポジトリを設定できますが、通常、古いインスタンスはトラブルシューティング目的でのみ使用され、統合で使用されることはありません。

Mavenプロジェクトに基づいてジョブを定義および実行する機能を持つ継続的ビルド・サーバー(Hudsonなど)は、SNAPSHOTアーティファクトが更新された場合に認識し、更新されたアーティファクトに依存するプロジェクトを再ビルドするように設定できます。

たとえば、Mavenプロジェクト・オブジェクト・モデルにマップするHudsonビルド構成にはSNAPSHOT依存性があります。Hudsonでは、SNAPSHOT更新に関してアーティファクト・リポジトリが定期的にチェックされます。プロジェクトの依存性の更新が検出されると、プロジェクトの新しいビルドがトリガーされ、依存性の最新バージョンを使用して統合が行われます。このプロジェクトに対する依存性が他のプロジェクトにある場合、それらのプロジェクトも更新された依存性で再ビルドされます。

7.3 バージョン範囲参照

Mavenを使用すると、依存性として許容できるバージョンの範囲を指定できます。表7-1に、バージョン範囲の仕様を示します。

表7-1 バージョン範囲参照

範囲

意味

(,1.0]

x <= 1.0

1.0

1.0が使用できない場合、通常は1.0以降のバージョンを意味します。

様々なMavenプラグインではこの相違の解釈が異なる場合があるため、より具体的な他のオプションを使用する方が安全です。

[1.0]

厳密に1.0

[1.2,1.3]

1.2 <= x <= 1.3

[1.0,2.0)

1.0 <= x < 2.0

[1.5,)

x >= 1.5

(,1.0],[1.2,)

x <= 1.0またはx >= 1.2

複数のセットはカンマで区切られます。

(,1.1),(1.1,)

1.1がライブラリとの組合せで機能しないことが判明している場合、1.1は除外されます。

Mavenでは、バージョン参照で複数の一致が見つかった場合、最も高い一致バージョンが使用されます。一般に、Mavenが必要に応じて新しいバージョンの依存性を自由に選択できるが、特定のバージョンの使用が必要なときはそれを認識できるようするために、バージョン参照は必要最低限に留める必要があります。これにより、異なるバージョンの依存性が推移的依存性グラフの複数箇所で指定された場合に、最適なバージョンがMavenで選択されます。このような競合が発生する場合、Mavenではすべての参照から最上位のバージョンが選択されます。

バージョン範囲を使用する選択肢があるため、SNAPSHOTバージョンを使用する有用性に疑問を持つかもしれません。バージョン範囲式を使用してある程度同じ結果を得ることもできますが、次の理由から、SNAPSHOTは継続的ビルド・システムでより適切に機能します。

- Mavenアーティファクト・リポジトリ・マネージャでは、SNAPSHOTが次期バージョン範囲よりも効率的に処理されます。単一のアーティファクトを1日に複数回デプロイできるため、リポジトリで保持される固有のインスタンスの数は急速に増える可能性があります。

- 非SNAPSHOTリリース・バージョンは無期限に保持されます。新しいバージョンを継続的にリリースし、ビルド番号やバージョンが増加していくと、記憶域要件はすぐに管理不能になります。リポジトリ・マネージャは、新しいインスタンス用の領域を確保するために古いSNAPSHOTを破棄するように設計されているため、必要となる記憶域容量は一定になります。

- SNAPSHOTは、MavenおよびMavenのリリース・プロセスでも認識されるため、リリース・ビルドの実行時に利点がもたらされます。

7.4 Oracle提供アーティファクトのMavenバージョン番号の理解

Mavenバージョン番号がOracle提供アーティファクトで使用される場合、次の2つの重要なシナリオがあります。

- アーティファクトのMaven座標、つまりアーティファクトのPOMのproject.version

- 他のアーティファクトを参照するPOMの依存性セクション

この項では、これら両方のシナリオでバージョン番号がOracleアーティファクトに定義される方法について説明します。

7.4.1 Maven座標のバージョン番号

POMファイルで定義されたアーティファクトのバージョン番号は、次で説明するように、リリース済製品のバージョン番号(5桁を使用して表される12.1.2.0.0など)と同じです。

x.x.x-y-zの場合:

- x.x.xは、12.1.2などのリリース・バージョン番号です。

- yは、0,1,2,3,…などの、先頭にゼロが付かないPatchSet番号です。

- zは、0,1,2,3,…などの、先頭にゼロが付かないBundle Patch番号です。

- ピリオドとハイフンはリテラルです。

注意:

(POMのproject.versionで指定した)アーティファクトのバージョン番号では、(POMのproject.dependencies.dependency.versionで指定した)依存性で使用されるバージョン番号範囲とは異なる形式が使用されます。

Oracle所有のコンポーネントのリリース・バージョン番号は、個別パッチで変更されません。リリース・バージョン番号は、リリースで変更され、コンポーネントが前のリリースで変更されていない場合でも、常にリリースと一致します。

パッチ・セット(4番目の位置)は、パッチ・セットを適用すると変更されます。バンドル・パッチ(5番目の位置)は、Bundle Patch、Patch set Updateまたは同等のパッチ(このタイプのパッチの名前は製品によって異なります)を適用した場合に変更されます。

次に、有効なバージョン番号の例を示します。

12.1.2-0-0    12.1.2-1-0   12.1.2-2-0
12.1.2-0-1    12.1.2-1-1   12.1.2-2-1
...
12.1.2-0-10   12.1.2-1-1   12.1.2-2-1

7.4.2 依存性でのバージョン番号範囲

Oracle提供のMavenアーティファクトで依存性が指定される2つの重要なシナリオは、次のとおりです。

- Oracle製品の一部であるアーティファクトのPOMファイル内

- 独自のプロジェクトに含めたPOMファイル内

バージョン番号範囲は、両方のシナリオで指定される必要があります。この項では、バージョン番号範囲がOracle提供のアーティファクトで指定される仕組み、およびOracle提供のアーティファクトで依存性を宣言するタイミングについて説明します。

他のアーティファクトで依存性を指定する場合は、具体的で正しい構文を使用して、不正または不適切なバージョンの依存性が定義で使用されないようにする必要があります。

[x.x.x,y.y.y)の場合:

- x.x.xは、12.1.2などのリリース・バージョン番号です。

- y.y.yは、12.1.3などの次回のリリース・バージョン番号です。

- 大カッコ、ピリオド、コマンドおよび小カッコは、リテラルです。

依存性の指定方法として正しい例は、次のとおりです。

[12.1.2,12.1.3)

表7-1で示しているように、前の例では、使用可能な最新バージョンは、12.1.2以降であり、かつ12.1.3よりも小さいことを示しています。

Oracle提供のアーティファクトで使用されるバージョン番号スキームにより、バージョン番号が正しくソートされるようになり、たとえば、次のバージョンは示された順序(古いものから新しいもの)でMavenによって解決されます。

12.1.2-0-0, 12.1.2-0-1, 12.1.2-0-2, 12.1.2-0-10, 12.1.2-1-0, 12.1.2-1-1, 12.1.2-1-2, 12.1.2-1-10, 12.1.2-0-0, 12.1.3-0-0

特定のパッチ・セットやバンドル・パッチに依存する依存性を指定する必要がある場合、たとえば、新しいAPIが導入された場合は、4番目または4番目と5番目の桁をそれぞれ含める必要があります。

次に例を示します。

[12.1.2-2,12.1.3)      depends on 12.1.2 with PatchSet 2
[12.1.2-2-5,12.1.3)     depends on 12.1.2 with PatchSet 2 and Bundle Patch 5

8 Maven POM継承を使用したビルド・プロセスのカスタマイズ

Oracleでは、特定の本番環境やランタイム環境またはOracle Fusion Middlewareをターゲットにしたすべてのプロジェクトに対して、ビルド・プロセスのカスタマイズを容易にする共通の親プロジェクト・オブジェクト・モデル(POM)のセットを提供しています。

Oracle提供の各Maven原型では、それぞれの親POMが、WebLogic ServerやCoherenceなど、原型が対象としているターゲット・ランタイム環境に特化したOracle提供の共通の親に設定されます。同様に、共通の親POM(本番またはターゲット・ランタイム環境ごとに1つずつ)では、それぞれの親POMが、Oracle Fusion Middlewareの共通の親に設定されます。

共通POMおよびOracle提供の原型は、次のような継承階層を形成します。

com.oracle.maven:oracle-common:12.1.2-0-0
- com.oracle.weblogic:wls-common:12.1.2-0-0
- com.oracle.weblogic.archetype:basic-webapp:12.1.2-0-0
- com.oracle.weblogic.archetype:basic-webapp-ejb:12.1.2-0-0
- com.oracle.weblogic.archetype:basic-webservice:12.1.2-0-0
- com.oracle.weblogic.archetype:basic-mdb:12.1.2-0-0
- com.oracle.coherence:gar-common:12.1.2-0-0
- com.oracle.coherence:maven-gar-archetype:12.1.2-0-0

たとえば、デフォルト・プロパティの設定、特定のプラグインに対するデフォルトの設定、Mavenプロファイルの定義などの、ビルド・プロセスのカスタマイズを行う場合、適切な親POMに定義を追加できます。たとえば、com.oracle.weblogic:wls-common:12.1.2-0-0に定義を追加した場合、WebLogic Maven原型から作成したすべてのプロジェクト(親を変更している場合を除く)および手動で作成したプロジェクトを含む、この親に関連するすべてのプロジェクトが影響を受けます。

これにより、各プロジェクトPOMに必要な設定の数を最小限に抑えることができます。たとえば、すべてのビルドを同じテスト・サーバーにデプロイしようとしている場合、次のカスタマイズ済の親WebLogic POMの例に示すように、com.oracle.weblogic:wls-maven-plugin:12.1.2-0-0に適切なビルド、プラグインおよびプラグイン・セクションを追加することによって、テスト・サーバーの詳細を提供できます。

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.oracle.weblogic.archetype</groupId>
<artifactId>wls-common</artifactId>
<version>12.1.2-0-0</version>
<packaging>pom</packaging>
<name>wls-common</name>
<parent>
<groupId>com.oracle.maven</groupId>
<artifactId>oracle-common</artifactId>
<version>12.1.2-0-0</version>
</parent>
<build>
<plugins>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>wls-maven-plugin</artifactId>
<version>12.1.2-0-0</version>
<executions>
<execution>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<user>weblogic</user>
<password>welcome1</password>
<verbose>true</verbose>
</configuration>
</execution>
</executions>
<configuration>
<middlewareHome>/home/oracle/fmwhome</middlewareHome>
</configuration>
</plugin>
</plugins>
</build>
</project>

同様に、任意のOracle Fusion Middlewareランタイムをターゲットとするすべてのプロジェクトに影響を与える場合は、com.oracle.maven:oracle-common:12.1.2-0-0にカスタマイズ内容を配置する必要があります。

共有内部リポジトリを使用している場合は、親POMをカスタマイズした後に、それらを共有Mavenリポジトリに公開します。

これらのカスタマイズがどのようにプロジェクトに持ち込まれるかを確認するには、プロジェクトのディレクトリから次のコマンドを使用して、プロジェクトのビルドに使用される完全なPOMを確認します。

mvn help:effective-pom

たとえばテスト環境に1セット、QA環境に1セットなど、複数の共有プロパティのセットを親POMに定義する場合は、Mavenプロファイルの使用を検討することをお薦めします。詳細は、次を参照してください:

http://www.sonatype.com/books/mvnref-book/reference/profiles.html

プロファイルを使用すると、コマンドラインに引数を設定することによって、またはPOM内の各種プロパティの有無に基づいて、特定のビルドに対して様々な設定をオンにすることができます。

9 Mavenを使用したWebLogic ServerのJava EEプロジェクトのビルド

この章では、WebLogic Maven原型を使用して、WebLogic Server Java EEアプリケーションを作成、ビルドおよびデプロイする方法について説明します。

この章の構成は、次のとおりです。

- 9.1項「Mavenを使用したJava EEプロジェクトのビルドの概要」

- 9.2項「Basic WebApp Maven原型の使用」

- 9.3項「Basic WebApp with EJB Maven原型の使用」

- 9.4項「Basic WebService Maven原型の使用」

- 9.5項「Basic MDB Maven原型の使用」

9.1 Mavenを使用したJava EEプロジェクトのビルドの概要

Oracle WebLogic Serverには、1つのMavenプラグインおよび4つの原型が提供されています。表9-1に、Maven座標を示します。

表9-1 WebLogic ServerでのMaven座標

アーティファクト

groupId

artifactId

version

WebLogic Serverプラグイン

com.oracle.weblogic

weblogic-maven-plugin

12.1.2-0-0

Basic WebApp原型

com.oracle.weblogic.archetype

basic-webapp

12.1.2-0-0

WebApp with EJB原型

com.oracle.weblogic.archetype

basic-webapp-ejb

12.1.2-0-0

Basic MDB原型

com.oracle.weblogic.archetype

basic-mdb

12.1.2-0-0

Basic WebServices原型

com.oracle.weblogic.archetype

basic-webservice

12.1.2-0-0

一般のMaven原型と同様、Oracle WebLogic Maven原型は、独自のアプリケーションをビルドするための一連の開始点および例となります。

9.2 Basic WebApp Maven原型の使用

Maven原型を使用して新しいBasic WebAppプロジェクトを作成するには、次のようなコマンドを発行する必要があります。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.weblogic.archetype
-DarchetypeArtifactId=basic-webapp
-DarchetypeVersion=12.1.2-0-0
-DgroupId=org.mycompany
-DartifactId=my-basic-webapp-project
-Dversion=1.0-SNAPSHOT

これにより、原型から新規プロジェクトを作成できるようにする、Mavenのarchetype:generateゴールが実行されます。表9-2に、これらのパラメータを示します。

表9-2 Basic WebAppプロジェクトのパラメータ

パラメータ

目的

archetypeGroupId

新規プロジェクトの作成に使用する原型のgroupIdを識別します。これは、前の例に示したように、com.oracle.weblogicである必要があります。

archetypeArtifactId

新規プロジェクトの作成に使用する原型のartifactIdを識別します。これは、前の例に示したように、basic-webappである必要があります。

archetypeVersion

新規プロジェクトの作成に使用する原型のバージョンを識別します。これは、前の例に示したように、12.1.2-0-0である必要があります。

groupId

新規プロジェクトのgroupIdを識別します。通常、これは組織のドメイン名を逆にした形式で始まります。

artifactId

新規プロジェクトのartifactIdを識別します。通常、これはプロジェクトの識別子です。

version

新規プロジェクトのバージョン番号を識別します。新規プロジェクトの場合、これは通常1.0-SNAPSHOTです。

また、次の例に示すように、引数なしでコマンドを実行することもできます。この場合、Mavenでは、使用可能な原型のリストが表示され、必要な情報の入力を求められます。

mvn archetype:generate

特定のリポジトリのみを参照するようにMavenを制限するには、-DarchetypeCatalogオプションを指定します。ローカル・リポジトリのみを参照する場合は値localを指定し、Mavenが参照するリポジトリを特定する場合はそのserverIdを指定します。これにより、表示される原型の数が制限され、コマンドの実行が高速になります。

プロジェクトを作成すると、そのプロジェクトには次のファイルが含まれます。

これらのファイルは、そのままデプロイ可能な小さなサンプル・アプリケーションを構成します。このアプリケーションを、独自のアプリケーションをビルドするための開始点として使用できます。

表9-3で説明されているように、プロジェクトには複数のファイルが含まれています。

表9-3 Basic WebAppプロジェクト用に作成されるファイル

ファイル

目的

pom.xml

新規プロジェクトについて記述するMavenプロジェクト・オブジェクト・モデル(POM)ファイル。プロジェクトに指定したMaven座標が含まれ、WebLogic Mavenプラグインを使用してプロジェクトをビルドするための適切なプラグイン定義も含まれます。

src/main/java下のファイル

データを格納するためにWebアプリケーションで使用されるサンプルのEnterprise Java Bean。

その他のすべてのファイル

Webアプリケーションのユーザー・インタフェースを構成するHTMLファイルおよびその他のファイル。

プロジェクト・コードを記述した後に、Mavenを使用してプロジェクトをビルドできます。サンプルをそのままビルドすることもできます。

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

- 環境にあわせたプロジェクト・オブジェクト・モデル・ファイルのカスタマイズ

- プロジェクトのコンパイル

- プロジェクトのパッケージ化

- Mavenを使用したWebLogic Serverへのプロジェクトのデプロイ

- 様々なオプションを使用したWebLogic Serverへのプロジェクトのデプロイ

- Basic WebAppプロジェクトのテスト

9.2.1 環境にあわせたプロジェクト・オブジェクト・モデル・ファイルのカスタマイズ

原型によって作成されるプロジェクト・オブジェクト・モデル(POM)ファイルは、ほとんどの場合そのままで十分です。POMを確認し、提供されているデフォルト値が現在の環境で使用している値と異なる設定がある場合は、その設定を更新する必要があります。

Archivaなどの内部Mavenリポジトリ・マネージャを使用している場合は、pluginRepositoryをPOMファイルに追加する必要があります。次に例を示しますが、これを現在の環境にあわせて変更できます。

<pluginRepositories>
<pluginRepository>
<id>archiva-internal</id>
<name>Archiva Managed Internal Repository</name>
<url>http://localhost:8081/archiva/repository/internal/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>

9.2.2 プロジェクトのコンパイル

プロジェクトでソース・コード(Java Beans、サーブレット、JSPなど)をコンパイルするには、次のコマンドを使用します。

mvn compile

標準のMavenプラグインを使用して、ソース・アーティファクトがクラス・ファイルにコンパイルされます。クラス・ファイルは、プロジェクトのtargetディレクトリにあります。

9.2.3 プロジェクトのパッケージ化

WARやEARファイルなどのデプロイ・アーカイブをビルドするには、次のコマンドを使用します。

mvn package

再度、標準のMavenプラグインを使用して、コンパイルされたアーティファクトおよびメタデータをデプロイ・アーカイブにパッケージ化します。packageなどのMavenゴールを実行すると、Mavenでは、そのゴールだけでなく、指定したゴールまで(そのゴールを含む)のすべてのゴールが実行されます。これは、標準のJava EEアプリケーションと非常によく似ていますが、プロジェクトにWebLogicデプロイメント・ディスクリプタがある場合は、それらもデプロイ・アーカイブにパッケージ化される点が異なります。

デプロイ・アーカイブ(この場合はWARファイル)は、プロジェクトのtargetディレクトリにあります。

9.2.4 Mavenを使用したWebLogic Serverへのプロジェクトのデプロイ

Mavenを使用してデプロイ・アーカイブをデプロイするには、次のコマンドを使用します。

mvn pre-integration-test

これにより、WebLogic Mavenプラグインのdeployゴールが実行されます。このゴールでは、標準タイプのすべてのデプロイ・アーカイブがサポートされます。

9.2.5 様々なオプションを使用したWebLogic Serverへのプロジェクトのデプロイ

プロジェクトをパッケージ化した後に、その他の既存(Maven以外)のメカニズムを使用してそれをWebLogic Serverにデプロイすることもできます。例として、WebLogic管理コンソール、ANTまたはWLSTスクリプトがあります。

9.2.6 Basic WebAppプロジェクトのテスト

Basic WebAppをテストするには、そのアプリケーションをデプロイしたWebLogic Server上で次のURLにアクセスします。

http://servername:7001/basicWebapp/index.xhtml

Basic WebAppのユーザー・インタフェースは次のようになります。

「アカウント名」および「金額」を指定し、「預入れ」を選択して、アプリケーションがどのように機能するかを確認します。

9.3 Basic WebApp with EJB Maven原型の使用

Maven原型によるBasic WebApp with EJBプロジェクトを使用するには、次の手順を実行します。

1. Maven原型を使用して新しいBasic WebAppプロジェクトを作成するには、次のようなコマンドを発行する必要があります。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.weblogic.archetype
-DarchetypeArtifactId=basic-webapp-ejb
-DarchetypeVersion=12.1.2-0-0
-DgroupId=org.mycompany
-DartifactId=my-basic-webapp-ejb-project
-Dversion=1.0-SNAPSHOT

これにより、原型から新規プロジェクトを作成できるようにする、Mavenのarchetype:generateゴールが実行されます。パラメータの詳細は、表9-4を参照してください。

表9-4 Basic WebApp with EJBプロジェクトのパラメータ

パラメータ

目的

archetypeGroupId

新規プロジェクトの作成に使用する原型のgroupIdを識別します。これは、前の例に示したように、com.oracle.weblogicである必要があります。

archetypeArtifactId

新規プロジェクトの作成に使用する原型のartifactIdを識別します。前の例で示したように、これはbasic-webapp-ejbである必要があります。

archetypeVersion

新規プロジェクトの作成に使用する原型のバージョンを識別します。これは、前の例に示したように、12.1.2-0-0である必要があります。

groupId

新規プロジェクトのgroupIdを識別します。通常、これは組織のドメイン名を逆にした形式で始まります。

artifactId

新規プロジェクトのartifactIdを識別します。通常、これはプロジェクトの識別子です。

version

新規プロジェクトのバージョン番号を識別します。新規プロジェクトの場合、これは通常1.0-SNAPSHOTです。

また、次の例に示すように、引数なしでコマンドを実行することもできます。この場合、Mavenでは、使用可能な原型のリストが表示され、必要な情報の入力を求められます。

mvn archetype:generate

プロジェクトを作成すると、そのプロジェクトには次のファイルが含まれます。

これらのファイルは、そのままデプロイ可能な小さなサンプル・アプリケーションを構成します。このアプリケーションを、独自のアプリケーションをビルドするための開始点として使用できます。

プロジェクトには複数のファイルが含まれており、各ファイルの目的は、表9-5で説明されています。

表9-5 Basic WebApp with EJBプロジェクト用に作成されるファイル

ファイル

目的

pom.xml

新規プロジェクトについて記述するMavenプロジェクト・オブジェクト・モデル(POM)ファイル。プロジェクトに指定したMaven座標が含まれ、WebLogic Mavenプラグインを使用してプロジェクトをビルドするための適切なプラグイン定義も含まれます。

src/main/java下のファイル

データを格納するためにWebアプリケーションで使用されるサンプルのEnterprise Java Bean。

その他のすべてのファイル

Webアプリケーションのユーザー・インタフェースを構成するHTMLファイルおよびその他のファイル。

2. プロジェクト・コードを記述した後に、Mavenを使用してプロジェクトをビルドできます。サンプルをそのままビルドすることもできます。

3. 環境にあわせてPOMをカスタマイズします。9.2.1項を参照してください。

4. Basic WebApp with EJBプロジェクトをコンパイルします。9.2.2項を参照してください。

5. Basic WebApp with EJBプロジェクトをパッケージ化します。9.2.3項を参照してください。

6. Basic WebApp with EJBプロジェクトをデプロイします。Mavenを使用したデプロイの詳細は、9.2.4項を参照してください。その他のオプションを使用したデプロイの詳細は、9.2.5項を参照してください。

7. Basic WebApp with EJBプロジェクトをテストします。
Basic WebApp with EJBをテストするには、そのアプリケーションをデプロイしたWebLogic Server上で次のURLにアクセスします。

http://servername:7001/basicWebapp/index.xhtml

Basic WebApp with EJBのユーザー・インタフェースは次のようになります。

「アカウント名」および「金額」を指定し、「預入れ」を選択して、アプリケーションがどのように機能するかを確認します。

9.4 Basic WebService Maven原型の使用

Maven原型によるBasic WebServiceプロジェクトを使用するには、次の手順を実行します。

1. Maven原型を使用して新しいBasic WebServiceプロジェクトを作成するには、次のようなコマンドを発行する必要があります。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.weblogic.archetype
-DarchetypeArtifactId=basic-webservice
-DarchetypeVersion=12.1.2-0-0
-DgroupId=org.mycompany
-DartifactId=my-basic-webservice-project
-Dversion=1.0-SNAPSHOT

これにより、原型から新規プロジェクトを作成できるようにする、Mavenのarchetype:generateゴールが実行されます。パラメータおよび説明の詳細は、表9-6を参照してください。

表9-6 Basic WebServiceプロジェクトのパラメータ

パラメータ

目的

archetypeGroupId

新規プロジェクトの作成に使用する原型のgroupIdを識別します。これは、前の例に示したように、com.oracle.weblogicである必要があります。

archetypeArtifactId

新規プロジェクトの作成に使用する原型のartifactIdを識別します。前の例で示したように、これはbasic-webserviceである必要があります。

archetypeVersion

新規プロジェクトの作成に使用する原型のバージョンを識別します。これは、前の例に示したように、12.1.2-0-0である必要があります。

groupId

新規プロジェクトのgroupIdを識別します。通常、これは組織のドメイン名を逆にした形式で始まります。

artifactId

新規プロジェクトのartifactIdを識別します。通常、これはプロジェクトの識別子です。

version

新規プロジェクトのバージョン番号を識別します。新規プロジェクトの場合、これは通常1.0-SNAPSHOTです。

また、次の例に示すように、引数なしでコマンドを実行することもできます。この場合、Mavenでは、使用可能な原型のリストが表示され、必要な情報の入力を求められます。

mvn archetype:generate

プロジェクトを作成すると、そのプロジェクトには次のファイルが含まれます。

これらのファイルは、そのままデプロイ可能な小さなサンプル・アプリケーションを構成します。このアプリケーションを、独自のアプリケーションをビルドするための開始点として使用できます。

プロジェクトには複数のファイルが含まれており、各ファイルの目的については、表9-7を参照してください。

表9-7 Basic WebServiceプロジェクト用に作成されるファイル

ファイル

目的

pom.xml

新規プロジェクトについて記述するMavenプロジェクト・オブジェクト・モデル(POM)ファイル。プロジェクトに指定したMaven座標が含まれ、WebLogic Mavenプラグインを使用してプロジェクトをビルドするための適切なプラグイン定義も含まれます。

SayHello.java

サンプルのWebサービス。

2. プロジェクト・コードを記述した後に、Mavenを使用してプロジェクトをビルドできます。サンプルをそのままビルドすることもできます。

3. 環境にあわせてPOMをカスタマイズします。9.2.1項を参照してください。

4. Basic WebServiceプロジェクトをコンパイルします。9.2.2項を参照してください。

5. Basic WebServiceプロジェクトをパッケージ化します。9.2.3項を参照してください。

6. Basic WebServiceプロジェクトをデプロイします。Mavenを使用したデプロイの詳細は、9.2.4項を参照してください。その他のオプションを使用したデプロイの詳細は、9.2.5項を参照してください。

7. Basic WebServiceプロジェクトをテストします。
Basic WebServiceをテストするには、そのサービスをデプロイしたWebLogic Server上で次のURLにアクセスします。

http://servername:7001/basicWebservice/SayHello

Basic WebServiceのユーザー・インタフェースは次のようになります。

WebサービスのWSDLにアクセスし、「テスト」リンクを選択して、Weblogic Webサービス・テスト・クライアントを開くことができます。これにより、Webサービスを呼び出し、出力を確認できます。

Webサービスをテストするには、左側パネルの「SayHello」操作を選択し、次の例に示すようにarg0の値を入力し、「呼出し」を選択します。

次の例に示すように、下にスクロールして、テスト結果を確認します。

9.5 Basic MDB Maven原型の使用

Maven原型によるBasic MDBプロジェクトを使用するには、次の手順を実行します。

1. Maven原型を使用して新しいBasic MDBプロジェクトを作成するには、次のようなコマンドを実行します。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.weblogic.archtype
-DarchetypeArtifactId=basic-mdb
-DarchetypeVersion=12.1.2-0-0
-DgroupId=org.mycompany
-DartifactId=my-basic-mdb-project
-Dversion=1.0-SNAPSHOT

これにより、原型から新規プロジェクトを作成できるようにする、Mavenのarchetype:generateゴールが実行されます。パラメータおよび説明については、表9-8を参照してください。

表9-8 Basic MDBプロジェクトのパラメータ

パラメータ

目的

archetypeGroupId

新規プロジェクトの作成に使用する原型のgroupIdを識別します。これは、前の例に示したように、com.oracle.weblogicである必要があります。

archetypeArtifactId

新規プロジェクトの作成に使用する原型のartifactIdを識別します。前の例で示したように、これはbasic-mdbである必要があります。

archetypeVersion

新規プロジェクトの作成に使用する原型のバージョンを識別します。これは、前の例に示したように、12.1.2-0-0である必要があります。

groupId

新規プロジェクトのgroupIdを識別します。通常、これは組織のドメイン名を逆にした形式で始まります。

artifactId

新規プロジェクトのartifactIdを識別します。通常、これはプロジェクトの識別子です。

version

新規プロジェクトのバージョン番号を識別します。新規プロジェクトの場合、これは通常1.0-SNAPSHOTです。

また、次の例に示すように、引数なしでコマンドを実行することもできます。この場合、Mavenでは、使用可能な原型のリストが表示され、必要な情報の入力を求められます。

mvn archetype:generate

プロジェクトを作成すると、そのプロジェクトには次のファイルが含まれます。

これらのファイルは、そのままデプロイ可能な小さなサンプル・アプリケーションを構成します。このアプリケーションを、独自のアプリケーションをビルドするための開始点として使用できます。

プロジェクトには複数のファイルが含まれており、各ファイルの目的については、表9-9を参照してください。

表9-9 Basic MDBプロジェクト用に作成されるファイル

ファイル

目的

pom.xml

新規プロジェクトについて記述するMavenプロジェクト・オブジェクト・モデル(POM)ファイル。プロジェクトに指定したMaven座標が含まれ、WebLogic Mavenプラグインを使用してプロジェクトをビルドするための適切なプラグイン定義も含まれます。

src/main/java下のファイル

データを格納するためにWebアプリケーションで使用されるサンプルのメッセージドリブンBean。

その他のすべてのファイル

Webアプリケーションのユーザー・インタフェースを構成するHTMLファイル。

2. プロジェクト・コードを記述した後に、Mavenを使用してプロジェクトをビルドできます。サンプルをそのままビルドすることもできます。

3. 環境にあわせてPOMをカスタマイズします。9.2.1項を参照してください。

4. Basic MDBプロジェクトをコンパイルします。9.2.2項を参照してください。

5. Basic MDBプロジェクトをパッケージ化します。9.2.3項を参照してください。

6. Basic MDBプロジェクトをデプロイします。Mavenを使用したデプロイの詳細は、9.2.4項を参照してください。その他のオプションを使用したデプロイの詳細は、9.2.5項を参照してください。

7. Basic MDBプロジェクトをテストします。
Basic MDBをテストするには、それをデプロイしたWebLogic Server上で次のURLにアクセスします。

http://servername:7001/basicMDB/index.xhtml

Basic MDBのユーザー・インタフェースは次のようになります。

「アカウント名」および「金額」を指定し、「預入れ」を選択します。

ユーザー・インタフェースで示されるように、WebLogic Serverの出力をチェックして、MDBによって出力されるメッセージを見つける必要があります。次の例のようになります。

The money has been deposited to frank, the balance of the account is 500.0

10 Mavenを使用したOracle Coherenceプロジェクトのビルド

この章では、Oracle Coherence原型を使用して、Oracle Coherenceプロジェクトを作成、ビルドおよびデプロイする方法について説明します。

次のトピックが含まれます:

- 10.1項「Mavenを使用したOracle Coherenceプロジェクトのビルドの概要」

- 10.2項「Maven原型からのプロジェクトの作成」

- 10.3項「Mavenを使用したプロジェクトのビルド」

- 10.4項「Mavenを使用したWebLogic Server Coherence Containerへのプロジェクトのデプロイ」

- 10.5項「さらに詳細な例のビルド」

10.1 Mavenを使用したOracle Coherenceプロジェクトのビルドの概要

Mavenプラグインおよび原型がOracle Coherenceグリッド・アーカイブ(GAR)プロジェクト用に提供されています。表10-1に、Maven座標を示します。

表10-1 CoherenceのMaven座標

アーティファクト

groupId

artifactId

version

Coherenceプラグイン

com.oracle.coherence

maven-gar-plugin

12.1.2-0-0

Coherence原型

com.oracle.coherence

maven-gar-archetype

12.1.2-0-0

表10-2に、Oracle Coherenceプラグインでサポートされているゴールを示します。

表10-2 Oracle Coherenceのゴール

ゴール

目的

generate-descriptor

プロジェクトのPOF構成ファイルを生成します。

package

ライブラリ依存性を含む基本的なGARアセットをJARアーカイブにパッケージ化します。

repackage

パッケージ化されたJARアーカイブをオプションのメタデータおよびGAR拡張を使用して再パッケージ化します。

10.2 Maven原型からのプロジェクトの作成

Coherence Maven原型を使用して新規Coherenceプロジェクトを作成するには、次のようなコマンドを発行する必要があります。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.coherence
-DarchetypeArtifactId=maven-gar-archetype
-DarchetypeVersion=12.1.2-0-0
-DgroupId=org.mycompany
-DartifactId=my-gar-project
-Dversion=1.0-SNAPSHOT

これにより、Mavenのarchetype:generateゴールが実行され、原型から新規プロジェクトを作成できます。表10-3に、パラメータを示します。

表10-3 Coherenceプロジェクトのパラメータ

パラメータ

目的

archetypeGroupId

新規プロジェクトの作成に使用する原型のgroup IDを識別します。これは、com.oracle.coherenceである必要があります。

archetypeArtifactId

新規プロジェクトの作成に使用する原型のartifact IDを識別します。これは、maven-gar-archetypeである必要があります。

archetypeVersion

新規プロジェクトの作成に使用する原型のバージョンを識別します。これは、12.1.2-0-0である必要があります。

groupId

新規プロジェクトのgroup IDを識別します。通常、これは組織のドメイン名を逆にした形式で始まります。

artifactId

新規プロジェクトのartifact IDを識別します。通常、これはプロジェクトの識別子です。

version

新規プロジェクトのversionを識別します。新規プロジェクトの場合、これは通常1.0-SNAPSHOTです。

また、次の例に示すように、引数なしでコマンドを実行することもできます。この場合、Mavenでは、使用可能な原型のリストが表示され、必要な情報の入力を求められます。

mvn archetype:generate

プロジェクトの作成後、プロジェクトには次のファイルが含まれます。

my-gar-project/
|-- pom.xml
`-- src
`-- main
|-- java
`-- resources
`-- META-INF
|-- cache-config.xml
|-- coherence-application.xml
`-- pof-config.xml

表10-4で説明されているように、プロジェクトには複数のファイルが含まれています。

表10-4 Coherenceプロジェクトのファイル

ファイル

目的

pom.xml

新規プロジェクトについて説明するMavenプロジェクト・オブジェクト・モデル(POM)ファイルであり、プロジェクトに指定したMaven座標が含まれ、Coherence Mavenプラグインを使用してプロジェクトをgarファイルにビルドするための適切なプラグイン定義も含まれています。

cache-config.xml

初期Coherenceキャッシュ構成ファイルです。

coherence-application.xml

GARファイルの初期Coherence GARデプロイメント・ディスクリプタです。

pof-config.xml

初期Coherence Portable Object Format (POF)構成ファイルです。プラグイン・オプションgeneratePofが「true」に設定されている場合、POF構成ファイルは処理され、最終GARファイルに挿入されます。デフォルトでは、POF構成メタデータは生成されません。

プロジェクトでPOFを使用する場合は、次のパラメータをプロジェクトのPOMファイルに追加する必要があります。

パラメータ

目的

generatePof

このプラグイン・オプションがtrueである場合は、POF構成ファイルが生成され、最終GARファイルに挿入されます。構成ファイルは、GARのクラスパスでクラスcom.tangosol.io.pof.annotation.Portableが注釈付けされたすべてのクラスをスキャンして生成されます。デフォルトでは、POF構成メタデータは生成されません。

適切に生成されたpof-config.xmlを使用してGARを生成するには、POMのGARプラグイン構成ファイルに次を追加します。

<build>
<plugins>
…
<plugin>
<groupId>com.oracle.coherence</groupId>
<artifactId>maven-gar-plugin</artifactId>
<version>12.1.2-0-0</version>
<extensions>true</extensions>
<configuration>
<generatePof>true</generatePof>
</configuration>
</plugin>
…
</plugins>
</build>

10.3 Mavenを使用したプロジェクトのビルド

プロジェクト・コードを記述した後に、Mavenを使用してプロジェクトをビルドできます。

プロジェクトのソース・コードをコンパイルするには、次のコマンドを実行します。

mvn compile

コンパイル済のソースをGARにパッケージ化するには、次のコマンドを入力します。これにより、パッケージ化までのすべてのステップ(コンパイルを含む)が実行されることに注意してください。

mvn package

10.4 Mavenを使用したWebLogic Server Coherence Containerへのプロジェクトのデプロイ

GARをWebLogic Server環境のCoherence Containerにデプロイするには、いくつかの追加構成をプロジェクトのPOMファイルに追加してGARをデプロイする必要があります。これは、次の例に示すように、Oracle WebLogic Mavenプラグインを使用してGARをデプロイする命令を追加することで行います。

<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.1.2-0-0</version>
<executions>
<!--Deploy the application to the server-->
<execution>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<adminurl>t3://localhost:7001</adminurl>
<user>weblogic</user>
<password>welcome1</password>
<!--The location of the file or directory to be deployed-->
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source>
<!--The target servers where the application is deployed-->
<targets>AdminServer</targets>
<verbose>true</verbose>
<name>${project.build.finalName}</name>
</configuration>
</execution>
</executions>
</plugin>

このセクションをPOMに追加した後、次のコマンドを使用してGARをコンパイルおよびパッケージ化し、WebLogic Serverにデプロイする必要があります。

mvn verify

10.5 さらに詳細な例のビルド

実際のアプリケーションでは、GARプロジェクトだけでなく、GARで確立されたCoherenceキャッシュを操作するなんらかのクライアント・プロジェクトも存在する場合があります。Coherence GARおよびCoherence GARと相互作用するWebアプリケーション(WAR)が含まれた例については、第11章「Mavenを使用した実際のアプリケーションのビルド」を参照してください。

11 Mavenを使用した実際のアプリケーションのビルド

多くの実際のアプリケーションには、様々なランタイム環境にデプロイすることを目的としたモジュールが含まれています。たとえば、Coherenceキャッシュに格納されているデータを使用するWebアプリケーションがあります。この章では、そのようなWebアプリケーションのビルド方法について説明します。

この章の構成は、次のとおりです。

- 11.1項「例の概要」

- 11.2項「複数モジュールのMavenプロジェクト」

- 11.3項「Mavenプロジェクトのビルドの開始」

- 11.4項「GARプロジェクトの作成」

- 11.5項「WARプロジェクトの作成」

- 11.6項「EARプロジェクトの作成」

- 11.7項「最上位POMの作成」

- 11.8項「Mavenを使用したアプリケーションのビルド」

11.1 例の概要

この章でビルドするアプリケーション例では、Webページ上にユーザーのリストが名前と年齢とともに表示されます。新規個人を追加することもできます。人々の詳細はCoherenceキャッシュに格納されます。このアプリケーションには、次の要素があります。

- ポータブル・オブジェクトに組み込む必要があるPerson POJO、キャッシュにアクセスするためのユーティリティ・クラス、およびCoherenceキャッシュ定義が含まれるCoherence GARプロジェクト。

- サーブレットとデプロイメント・ディスクリプタが含まれた、WARに組み込む必要があるJava EE Webアプリケーション。

- GARおよびWARをEARにアセンブルし、そのEARをWebLogic Serverにデプロイするプロジェクト。

この例では、モジュール間に依存性がある複数モジュールのMavenプロジェクトをビルドする方法、アプリケーション全体が含まれたデプロイ可能EARファイルにアプリケーション・コンポーネントをアセンブルする方法を確認できます。

この章の目的は、Mavenを使用してアプリケーション全体をビルドする方法を示すことであり、WebアプリケーションまたはCoherenceアプリケーションの記述方法をデモンストレーションすることではないため、例自体の内容は、サーブレットおよびcoherenceコードの観点から見れば非常に基本的なものです。詳細は、第9章および第10章を参照してください。

11.2 複数モジュールのMavenプロジェクト

Mavenを使用すると、複数のモジュールを持つプロジェクトを作成できます。各モジュールは、別のMavenプロジェクトで有効です。最上位レベルには、モジュールに関する情報をMavenに示し、アプリケーション全体を1つのMavenコマンドでビルドできるPOMファイルがあります。

各モジュールは、最上位プロジェクトのルートのサブディレクトリに配置されます。この例では、最上位プロジェクトはmy-real-appと呼ばれ、3つのモジュールはmy-real-app-gar、my-real-app-warおよびmy-real-app-earです。プロジェクトのMaven座標は、次のとおりです。

GroupId

ArtifactId

バージョン

パッケージ化

org.mycompany

my-real-app

1.0-SNAPSHOT

pom

org.mycompany

my-real-app-gar

1.0-SNAPSHOT

gar

org.mycompany

my-real-app-war

1.0-SNAPSHOT

war

org.mycompany

my-real-app-ear

1.0-SNAPSHOT

ear

アプリケーションを構成しているファイルは、次のとおりです。

pom.xml

my-real-app-gar/pom.xml
my-real-app-gar/src/main/resources/META-INF/pof-config.xml
my-real-app-gar/src/main/resources/META-INF/coherence-application.xml
my-real-app-gar/src/main/resources/META-INF/cache-config.xml
my-real-app-gar/src/main/java/org/mycompany/CacheWrapper.java
my-real-app-gar/src/main/java/org/mycompany/Person.java

my-real-app-war/pom.xml
my-real-app-war/src/main/webapp/WEB-INF/web.xml
my-real-app-war/src/main/java/org/mycompany/servlets/MyServlet.java

my-real-app-ear/pom.xml
my-real-app-ear/src/main/application/META-INF/weblogic-application.xml

最上位レベルでは、POMファイルは3つのモジュールを指しています。

my-real-app-garディレクトリには、Coherence GARプロジェクトが含まれています。独自のPOM、Coherence構成ファイル、POJO/POFクラス定義(Person.java)、キャッシュへのアクセスに必要なユーティリティ・クラス(CacheWrapper.java)が含まれています。

my-real-app-warディレクトリには、Webアプリケーションが含まれています。独自のPOM、サーブレットおよびデプロイメント・ディスクリプタが含まれています。このプロジェクトは、my-real-app-garプロジェクトに依存します。

my-real-app-earディレクトリには、EARファイルのデプロイメント・ディスクリプタ、およびEARをビルドおよびデプロイするためのPOMファイルが含まれています。

11.3 Mavenプロジェクトのビルドの開始

次のコマンドを使用して、プロジェクトを保持するためのディレクトリを作成します。

mkdir my-real-app

この章の残りの部分では、このディレクトリに対する相対パスが示されます。

11.4 GARプロジェクトの作成

10.2項で説明しているように原型を使用するか、またはディレクトリおよびファイルを手動で作成して、GARプロジェクトを作成できます。

原型を使用するには、次のコマンドを実行します。

mvn archetype:generate
-DarchetypeGroupId=com.oracle.coherence
-DarchetypeArtifactId=maven-gar-archetype
-DarchetypeVersion=12.1.2-0-0
-DgroupId=org.mycompany
-DartifactId=my-real-app-gar
-Dversion=1.0-SNAPSHOT

プロジェクトを手動で作成するには、次のコマンドを使用して、必要なディレクトリを作成します。

mkdir -p my-real-app-gar/src/main/resources/META-INF
mkdir -p my-real-app-gar/src/main/java/org/mycompany

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

- 11.4.1項「POMファイル」

- 11.4.2項「Coherenceの構成ファイルの作成または変更」

- 11.4.3項「ポータブル・オブジェクトの作成」

- 11.4.4項「キャッシュにアクセスするためのラッパー・クラスの作成」

11.4.1 POMファイル

原型を使用する場合、POMファイルはすでに存在します。次の例に一致するようにファイルを変更する必要があります。プロジェクトを手動で作成する場合は、次の内容のPOMファイル(my-real-app-gar/pom.xml)を作成する必要があります。

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>gar</packaging>
<parent>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>com.oracle.coherence</groupId>
<artifactId>coherence</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>com.oracle.coherence</groupId>
<artifactId>maven-gar-plugin</artifactId>
<version>${coherence.version}</version>
<extensions>true</extensions>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>com.oracle.coherence</groupId>
<artifactId>maven-gar-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<generatePof>true</generatePof>
</configuration>
</plugin>
</plugins>
</build>
</project>

POMファイルを調べて、各部分が何を表すかを理解します。このプロジェクトのMaven座標は、次のように設定されます。

<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>gar</packaging>

Coherence Mavenプラグインを使用してこのプロジェクトをCoherence GARファイルにビルドするため、パッケージ化がgarであることに注意してください。

親プロジェクトの座標が設定されます。これらの座標は、最上位プロジェクトを指します。最上位プロジェクトのPOMを後の手順で作成する必要があります。

<parent>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>

dependenciesセクションは、このプロジェクトが持っている依存性を示しています。この場合、Coherenceライブラリ、つまりcom.oracle.coherence:coherence:12.1.2-0-0にのみ依存します。スコープprovidedは、このライブラリが単にコンパイル用であり、ランタイム環境ですでに提供されているため、ビルドするアーティファクト(GARファイル)でパッケージ化する必要がないことを意味します。

<dependencies>
<dependency>
<groupId>com.oracle.coherence</groupId>
<artifactId>coherence</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
</dependencies>

pluginManagementセクションは、このプラグインの拡張を有効にするようMavenに示します。MavenでGARファイルをターゲット・アーティファクト・タイプとして認識できるようにする必要があります。

<pluginManagement>
<plugins>
<plugin>
<groupId>com.oracle.coherence</groupId>
<artifactId>maven-gar-plugin</artifactId>
<version>${coherence.version}</version>
<extensions>true</extensions>
</plugin>
</plugins>
</pluginManagement>

plug-insセクションには、Coherence GARプラグインに渡す必要がある情報が含まれています。この場合、generatePofをtrueに設定して、プラグインでPOF注釈付きPOJOが検索され、必要なアーティファクトが生成されるようにする必要があります。

<plugins>
<plugin>
<groupId>com.oracle.coherence</groupId>
<artifactId>maven-gar-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<generatePof>true</generatePof>
</configuration>
</plugin>
</plugins>

11.4.2 Coherenceの構成ファイルの作成または変更

GARプロジェクトに必要なCoherence構成ファイルは3つあります。原型を使用する場合、ファイルはすでに存在しますが、次の例に一致するように変更する必要があります。プロジェクトを手動で作成する場合は、次に示す場所にこれらのファイルを作成する必要があります。

my-real-app-gar/src/main/resources/META-INF/pof-config.xml
my-real-app-gar/src/main/resources/META-INF/coherence-application.xml
my-real-app-gar/src/main/resources/META-INF/cache-config.xml

pof-config.xmlファイルの内容を次に示します。

<?xml version="1.0"?>
<pof-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-pof-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-pof  -config coherence-pof-config.xsd">
<user-type-list>
<!-- by default just include coherence POF user types -->
<include>coherence-pof-config.xml</include>
</user-type-list>
</pof-config>

coherence-application.xmlファイルの内容を次に示します。

<?xml version="1.0" encoding="ISO-8859-1"?>
<coherence-application xmlns="http://xmlns.oracle.com/weblogic/coherence-application">
<cache-configuration-ref>META-INF/cache-config.xml</cache-configuration-ref>
<pof-configuration-ref>META-INF/pof-config.xml</pof-configuration-ref>
</coherence-application>

これらのファイルは、原型を使用して作成した場合、変更する必要がほとんどないか、またはまったくありません。

cache-config.xmlファイルは、原型を使用した場合、次のように更新する必要があります。

このファイルでは、Peopleという名前のキャッシュおよびreal-distributed-garという名前のキャッシュ・スキームを作成し、(ローカル・バッキング・スキームを使用し、自動的に開始される) RealDistributedCacheという名前のサービスを作成します。これらの用語に精通していない場合は、第10章を参照してください。

<?xml version="1.0"?>
<cache-config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-cache-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-cache-config coherence-cache-config.xsd">

<caching-scheme-mapping>
<cache-mapping>
<cache-name>People</cache-name>
<scheme-name>real-distributed-gar</scheme-name>
</cache-mapping>
</caching-scheme-mapping>

<caching-schemes>
<distributed-scheme>
<scheme-name>real-distributed-gar</scheme-name>
<service-name>RealDistributedCache</service-name>
<backing-map-scheme>
<local-scheme/>
</backing-map-scheme>
<autostart>true</autostart>
</distributed-scheme>
</caching-schemes>
</cache-config>

11.4.3 ポータブル・オブジェクトの作成

キャッシュに情報を格納するPersonオブジェクトを作成します。新しいJavaクラスを次の場所に作成します。

my-real-app-gar/src/main/java/org/mycompany/Person.java

クラスの内容を次に示します。

package org.mycompany;

import com.tangosol.io.pof.annotation.Portable;
import com.tangosol.io.pof.annotation.PortableProperty;

@Portable
public class Person {
@PortableProperty(0)
public String name;
@PortableProperty(1)
public int age;

public Person() {}

public Person(String name, int age) {
this.name = name;
this.age = age;
}

public String getName() { return this.name; }
public int    getAge()  { return this.age;  }
}

POJOは、このクラスで何を実行するかをCoherenceに示します。この章では、Mavenを使用したアプリケーションのビルドに焦点を当てており、Coherenceアプリケーションの記述の詳細には触れていません。Coherenceの詳細は、第10章を参照してください。

11.4.4 キャッシュにアクセスするためのラッパー・クラスの作成

キャッシュのアクセスに使用できる小さなラッパー・クラスを作成します。別のJavaクラスを次の場所に作成します。

my-real-app-gar/src/main/java/org/mycompany/CacheWrapper.java

クラスの内容を次に示します。

package org.mycompany;

import org.mycompany.Person;
import com.tangosol.net.CacheFactory;
import java.util.Set;

public class CacheWrapper {
private static CacheWrapper INSTANCE;

public Set getPeople() {
return CacheFactory.getCache("People").entrySet();
}

public void addPerson(int personid, String name, int age) {
CacheFactory.getCache("People").put(personid, new Person(name, age));
}

public static final CacheWrapper getInstance() {
if(INSTANCE == null) INSTANCE = new CacheWrapper();
return INSTANCE;
}
}

後で、このクラスをサーブレットで使用して、キャッシュからデータを取得したり、新しいデータをキャッシュに追加することができます。

11.5 WARプロジェクトの作成

第9章で説明しているように原型を使用するか、またはディレクトリおよびファイルを手動で作成して、WARプロジェクトを作成できます。

原型を使用するには、次のコマンドを実行します。

mvn archetype:generate
-DarchetypeArtifactId=basic-webapp
-DarchetypeVersion=12.1.2-0-0
-DgroupId=org.mycompany
-DartifactId=my-real-app-war
-Dversion=1.0-SNAPSHOT

原型を使用する場合は、プロジェクトに含まれている不要なファイルをすべて削除する必要があります。

プロジェクトを手動で作成するには、次のコマンドを使用して、必要なディレクトリを作成します。

mkdir -p my-real-app-war/src/main/webapp/WEB-INF
mkdir -p my-real-app-war/src/main/java/org/mycompany/servlets

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

- 11.5.1項「POMファイルの作成または変更」

- 11.5.2項「デプロイメント・ディスクリプタの作成」

- 11.5.3項「サーブレットの作成」

11.5.1 POMファイルの作成または変更

原型を使用する場合は、POMファイルがすでに存在します。次の例に一致するようにファイルを変更する必要があります。プロジェクトを手動で作成した場合は、次の内容のPOMファイル(my-real-app-war/pom.xml)を作成する必要があります。

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-war</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<parent>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<name>my-real-app-war</name>
<dependencies>
<dependency>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
</dependencies>
</project>

POMファイルに含まれている内容を確認します。最初に、このプロジェクトの座標を設定する必要があります。このプロジェクトのパッケージ化はwarであることに注意してください。

<groupId>org.mycompany</groupId>
<artifactId>my-real-app-war</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>

次に、GARプロジェクトの場合と同様に親を定義します。

<parent>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>

最後に、このプロジェクトの依存性をリストします。この場合、2つの依存性があります(POJOおよびそこで定義されたユーティリティ・クラスにアクセスするためのGARプロジェクト、およびサーブレットAPI)。これにより、Webアプリケーションの表示名が設定されます。

<dependencies>
<dependency>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
</dependencies>

11.5.2 デプロイメント・ディスクリプタの作成

Webアプリケーションには、次の場所にある単純なJava EEデプロイメント・ディスクリプタがあります。

my-real-app-war/src/main/webapp/WEB-INF/web.xml

このファイルの内容を次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">

<display-name>my-real-app-war</display-name>

</web-app>

これにより、Webアプリケーションのdisplay-nameが設定されます。

11.5.3 サーブレットの作成

サーブレットを作成するには、次のようにMyServlet.javaファイルを検索します。

my-real-app-war/src/main/java/org/mycompany/servlets/MyServlet.java

サーブレットでは、現在キャッシュ内に存在する個人のリストが表示され、新規個人をキャッシュに追加できます。この項の目的は、Mavenを使用してこれらのタイプのアプリケーションをビルドする方法を学習することであり、Java EE Webアプリケーションの記述方法を学習することではないため、単純なサーブレットを使用しています。

サーブレット・クラスの内容を次に示します。

package org.mycompany.servlets;

import org.mycompany.Person;
import org.mycompany.CacheWrapper;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Map;
import java.util.Set;
import java.util.Iterator;

@WebServlet(name = "MyServlet", urlPatterns = "MyServlet")
public class MyServlet extends HttpServlet {
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String id = request.getParameter("id");
String name = request.getParameter("name");
String age = request.getParameter("age");
if (name == null || name.isEmpty()
|| age == null || age.isEmpty()
|| id == null || id.isEmpty()) {
// no need to add a new entry
} else {
// we have a new entry - so add it
CacheWrapper.getInstance().addPerson(Integer.parseInt(id), name, Integer.parseInt(age));
}
renderPage(request, response);
}

protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
renderPage(request, response);
}

private void renderPage(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
// get the data
Set people = CacheWrapper.getInstance().getPeople();
PrintWriter out = response.getWriter();
out.write("<html><head><title>MyServlet</title></head><body>");
out.write("<h2>Add a new person</h2>");
out.write("<form name=\"myform\" method=\"POST\">");
out.write("ID:<input type=\"text\" name=\"id\"/><br/>");
out.write("Name:<input type=\"text\" name=\"name\"/><br/>");
out.write("Age:<input type=\"text\" name=\"age\"/><br/>");
out.write("<input type=\"submit\" name=\"submit\" value=\"add\"/>");
out.write("</form>");
out.write("<h2>People in the cache now</h2>");
out.write("<table><tr><th>ID</th><th>Name</th><th>Age</th></tr>");
// for each person in data
if (people != null) {
Iterator i = people.iterator();
while (i.hasNext()) {
Map.Entry entry = (Map.Entry)i.next();
out.write("<tr><td>"
+ entry.getKey()
+ "</td><td>"
+ ((Person)entry.getValue()).getName()
+ "</td><td>"
+ ((Person)entry.getValue()).getAge()
+ "</td></tr>");
}
}
out.write("</table></body></html>");
}
}

ユーザーがフォームにデータを入力したかどうかをチェックします。その場合は、そのデータを使用して新規個人をキャッシュに追加します。このアプリケーションでは、最小限のエラー処理しか行われないことに注意してください。新規個人をキャッシュに追加するには、GARプロジェクトで作成したCacheWrapperクラスでaddPerson()メソッドを使用します。

キャッシュの内容を表に出力します。この例では、キャッシュに含まれているエントリが十分に少ないと想定し、CacheWrapperクラスのgetPeople()メソッドを使用してすべてを読み取ります。

11.6 EARプロジェクトの作成

EARプロジェクトは、EARへのWARおよびGARのアセンブルを管理します。次のコマンドを使用して、このプロジェクトを手動で作成します。

mkdir -p my-real-app-ear/src/main/application/META-INF

このプロジェクトには、次の2つのファイル(POMファイルとデプロイメント・ディスクリプタ)があります。

my-real-app-ear/pom.xml

my-real-app-ear/src/main/application/META-INF/weblogic-application.xml

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

- 11.6.1項「POMファイル」

- 11.6.2項「デプロイメント・ディスクリプタ」

11.6.1 POMファイル

POMファイルの内容を次に示します。

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-ear</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>ear</packaging>
<parent>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<name>ear assembly</name>
<dependencies>
<dependency>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<type>gar</type>
<scope>optional</scope>
</dependency>
<dependency>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-war</artifactId>
<version>1.0-SNAPSHOT</version>
<type>war</type>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
<artifactTypeMappings>
<artifactTypeMapping type="gar" mapping="jar"/>
</artifactTypeMappings>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-gar-locally</id>
<phase>prepare-package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<type>gar</type>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.1.2-0-0</version>
<executions>
<!--Deploy the application to the server-->
<execution>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>welcome1</password>
<middlewareHome>/home/mark/space/maven/wls030213</middlewareHome>
<!--The location of the file or directory to be deployed-->
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source>
<!--The target servers where the application is deployed-->
<targets>AdminServer</targets>
<verbose>true</verbose>
<name>${project.build.finalName}</name>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>

次のように、このプロジェクトのMaven座標を設定し、親を指すように設定します。

<groupId>org.mycompany</groupId>
<artifactId>my-real-app-ear</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>ear</packaging>
<parent>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>

次に、WARプロジェクトとGARプロジェクトには次のような依存性があります。

<dependencies>
<dependency>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<type>gar</type>
<scope>optional</scope>
</dependency>
<dependency>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-war</artifactId>
<version>1.0-SNAPSHOT</version>
<type>war</type>
</dependency>
</dependencies>

3つの個別のプラグイン構成があります。これらの1番目はmaven-ear-pluginです。次の例のようにartifactTypeMappingを追加して、garファイルをjarファイルのように処理するよう指定する必要があります。

<plugin>
<artifactId>maven-ear-plugin</artifactId>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
<artifactTypeMappings>
<artifactTypeMapping type="gar" mapping="jar"/>
</artifactTypeMappings>
</configuration>
</plugin>

GARファイルをmy-real-app-garプロジェクトの出力(target)ディレクトリからEARプロジェクトにコピーするようにmaven-dependency-pluginを構成します。

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-gar-locally</id>
<phase>prepare-package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app-gar</artifactId>
<version>1.0-SNAPSHOT</version>
<type>gar</type>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>

最後に、結果として生成されるEARファイルのデプロイ方法をweblogic-maven-pluginに指定します。この項では、環境に一致するようにadminurl、user、passwordおよびtargetの各パラメータを更新する必要があります。これらのパラメータの詳細は、表9-1を参照してください。

<plugin>
<groupId>com.oracle.weblogic</groupId>
<artifactId>weblogic-maven-plugin</artifactId>
<version>12.1.2-0-0</version>
<executions>
<!--Deploy the application to the server-->
<execution>
<phase>pre-integration-test</phase>
<goals>
<goal>deploy</goal>
</goals>
<configuration>
<adminurl>t3://127.0.0.1:7001</adminurl>
<user>weblogic</user>
<password>welcome1</password>
<!--The location of the file or directory to be deployed-->
<source>${project.build.directory}/${project.build.finalName}.${project.packaging}</source>
<!--The target servers where the application is deployed-->
<targets>AdminServer</targets>
<verbose>true</verbose>
<name>${project.build.finalName}</name>
</configuration>
</execution>
</executions>
</plugin>

POMプロジェクトが完了したら、デプロイメント・ディスクリプタを追加します。

11.6.2 デプロイメント・ディスクリプタ

EARファイルのWebLogicデプロイメント・ディスクリプタは、次のファイルにあります。

my-real-app-ear/src/main/application/META-INF/weblogic-application.xml

内容を次に示します。

<weblogic-application>
<module>
<name>GAR</name>
<type>GAR</type>
<path>my-real-app-gar-1.0-SNAPSHOT.gar</path>
</module>
</weblogic-application>

このデプロイメント・ディスクリプタでは、EARファイル内でGARファイルが配置されている場所、およびその呼び名に関する詳細が示されます。

11.7 最上位POMの作成

最上位POMを作成します。これは、アプリケーションのルート・ディレクトリ内のpom.xmlファイルにあり、その内容は次のとおりです。

<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.mycompany</groupId>
<artifactId>my-real-app</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>my-real-app</name>
<modules>
<module>my-real-app-war</module>
<module>my-real-app-gar</module>
<module>my-real-app-ear</module>
</modules>
<properties>
<coherence.version>12.1.2-0-0</coherence.version>
</properties>
</project>

プロジェクトの座標を設定します。3つの各プロジェクトで指定した親座標にこれらが一致することに注意してください。パッケージ化がpomであることに注意してください。これにより、modulesセクションで指定しているように、このプロジェクトが一連のサブプロジェクトのアセンブリであることがMavenに示されます。

3つのサブプロジェクトそれぞれに1つのmoduleエントリがあります。

このPOMは他の3つの親であり、POMはそれらの親から継承されるため、一般的なプロパティをこのPOMに追加でき、それらのプロパティは3つのサブプロジェクトすべてで利用できるようになります。この場合、プロパティcoherence.versionを追加します。

11.8 Mavenを使用したアプリケーションのビルド

これで、次のコマンドを(最上位ディレクトリmy-real-appで)1つ以上使用して、Mavenによるアプリケーションのビルドを実行できるようになります。

mvn compile
mvn package
mvn verify

Mavenでは、指定したフェーズまでのすべてのフェーズが実行されます。これらのコマンドによる結果を次に示します。

コマンド

詳細

mvn compile

Javaソースをターゲット・クラス・ファイルにコンパイルします。

mvn package

1. Javaソースをターゲット・クラス・ファイルにコンパイルします。

2. コンパイルされたファイルおよびリソース(デプロイメント・ディスクリプタ、構成ファイルなど)を含むアーカイブ(WAR、GARなど)を作成します。

mvn verify

1. Javaソースをターゲット・クラス・ファイルにコンパイルします。

2. コンパイルされたファイルおよびリソース(デプロイメント・ディスクリプタ、構成ファイルなど)を含むアーカイブ(WAR、GARなど)を作成します。

3. EARファイルをWebLogic Server環境にデプロイします。

12 ビルド自動化から継続的インテグレーションへ

この章では、単純なビルド自動化から継続的インテグレーション環境への移行に際して考慮する必要がある重要事項について、簡単に概要を説明します。

このマニュアルに記載されている各例に従って読み進めてきた場合は、Oracle Fusion Middleware環境でのデプロイメントを目的としたプロジェクトのビルド・プロセスを、Mavenを使用して管理する方法について理解できています。

次の論理的なステップとしては、継続的インテグレーション・アプローチに移行し、すべてのプロジェクトのビルドを中心となる1つの場所からトリガー、管理および監視できるようにします。

継続的インテグレーションの利点は、アプリケーションのコンポーネント化と、それらのコンポーネントが、多くの場合異なる開発者グループによって個別に変更されながら、継続的に統合されることによってもたらされます。Mavenプロジェクトは、これらのコンポーネントとそれらの相互関係を表すのに使用されます。HudsonではMavenのプロジェクト関係モデルが認識されるため、影響を受けるコンポーネントを、必要なビルドの順序に従って自動的に再ビルドおよび再テストできます。Hudsonによってコードベースに対する変更が検出されると、影響を受けるコンポーネントは、アプリケーション全体が適切に機能するように、正しい順序でビルドおよび再統合されます。

この章では、Hudsonを使用した継続的インテグレーション環境への移行の際に考慮すべき重要事項について説明します。この章の内容は次のとおりです。

- 12.1項「依存性管理」

- 12.2項「継続的インテグレーション・デプロイメントをサポートするMaven構成」

- 12.3項「Hudsonを使用したビルドの自動化」

- 12.4項「ビルドの監視」

12.1 依存性管理

依存性管理はMavenの主要機能であり、Fusion Middlewareで当面サポートされるANTなどの他のビルド自動化テクノロジとMavenを区別化する機能です。この項では、依存性管理の重要項目について説明します。

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

- 12.1.1項「SNAPSHOTの使用」

- 12.1.2項「依存の推移性」

- 12.1.3項「依存性のスコープ」

- 12.1.4項「複数モジュールのサポート」

12.1.1 SNAPSHOTの使用

スナップショットのバージョニングについては、第7章で詳細に説明されています。自動化された継続的インテグレーション・システムが正しく動作するには、開発中のコンポーネントのスナップショットを使用することが必要です。修正バージョン、つまりスナップショットではないバージョンのアーティファクトは変更および置換しないように注意してください。ベスト・プラクティスは、アーティファクトのリリース後にこれらのアーティファクトを更新しないようにすることです。これは、Mavenアプローチの中心となる前提です。ただしここで注目されるのは、多くの場合、企業のソフトウェア開発においてこの前提が適切でないという点であり、ベンダーやエンド・ユーザーは、バージョン番号を変更せずに、たとえば該当場所にパッチを適用することによって、最終的なアーティファクトを更新することがあります。このルールに違反することが可能であっても、インテグレーションの安定性を確実にするために、最大限の努力をしてこのルールに従うことが必要です。

12.1.2 依存の推移性

大部分のプロジェクトは他のアーティファクトに対する依存性を備えています。ビルド時にMavenは構成済のアーティファクト・リポジトリからこれらのアーティファクトを取得し、これらを使用してコンパイル、ランタイム、およびテストにおける依存性を解決します。

POMに明確に一覧されている依存性には、それら自身の依存関係が含まれている場合もあります。これを一般に推移的な依存性と呼びます。スコープやバージョンなどの依存属性を基に、Mavenはルールを使用して、ビルドで利用する必要がある依存性を決定します。この解決プロセスの重要な部分は、バージョン競合と関係しています。プロジェクトは、同じアーティファクト(同一のgroupIdおよびartifactId)の複数バージョンに対して推移的な依存性を持つ場合があります。この場合、Mavenは最も近い定義を使用します。つまり、依存性のツリーにおいてプロジェクトに最も近い依存性を持つバージョンを使用します。プロジェクトのPOMで特定のバージョンを明示的に宣言すると、常にそのバージョンを保証できます。

注意:

依存性のツリーの同じ深さに2つの依存性バージョンが存在する場合、Maven 2.0.8まではどちらが優先されるか定義されていませんでしたが、Maven 2.0.9以降は宣言の順序で決定されます。つまり、最初に宣言されたバージョンが優先されます。

12.1.3 依存性のスコープ

依存性では必要に応じてスコープを指定できます。スコープは、特定のビルド・フェーズで依存性をクラスパスに対して使用可能にするかどうかを決定するだけでなく、推移的な依存性がクラスパスに伝播される方法にも影響を与えます。

6つのスコープが使用可能です。

- コンパイル: これがデフォルトのスコープで、スコープの指定がない場合はこれが使用されます。コンパイル依存性は、プロジェクトのすべてのクラスパスで使用可能です。さらに、これらの依存性は依存プロジェクトに伝播されます。

- 提供済: これはコンパイルとよく似ていますが、ランタイムの依存性の提供にJDKまたはコンテナを期待していることを示します。たとえば、Java Enterprise EditionのWebアプリケーションをビルドする場合、Webコンテナでこれらのクラスが提供されるため、サーブレットAPIおよび関連するJava EE APIに対する依存性を提供済スコープに設定できます。このスコープはコンパイルおよびテスト・クラスパスでのみ使用可能であり、推移的ではありません。

- ランタイム: このスコープは、依存性がコンパイルには不要で実行には必要であることを示します。ランタイムおよびテスト・クラスパスで使用されますが、コンパイル・クラスパスでは使用されません。

- テスト: このスコープは、アプリケーションの通常使用では依存性が不要であり、テスト・コンパイルおよび実行フェーズでのみ使用可能であることを示します。

- システム: このスコープは提供済と似ていますが、このスコープを含むJARを明示的に提供する必要があります。アーティファクトは常に使用可能であり、リポジトリ内で検索されることはありません。

- インポート: (Maven 2.0.9以降でのみ使用可能)このスコープは、タイプPOMの依存性においてのみ使用されます。これは、指定したPOMをそのPOMの依存性で置き換える必要があることを示します。このように置き換えられるため、インポートのスコープを持つ依存性は実際には依存の推移性の制限に関与しません。

12.1.4 複数モジュールのサポート

アプリケーションなどの一連の非依存プロジェクトは、複数モジュールのPOMで集約できます。これを、継承された構成を提供する親POMと混同しないようにしてください。複数モジュールのPOMは、サブモジュール・プロジェクトへの継承の親になる場合もあります。Mavenビルドが複数モジュールのPOMで実行されると、Mavenはサブプロジェクトのツリーを調べて、モジュールをビルドするための正しい依存順序を決定します。

複数モジュールのPOMは、Hudsonでの複数コンポーネント・ビルドの編成に役立ちます。

12.2 継続的インテグレーション・デプロイメントをサポートするMaven構成

この項では、継続的インテグレーション環境への移行の際に考慮する必要があるMavenのいくつかの局面について説明します。

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

- 12.2.1項「配布管理」

- 12.2.2項「スナップショット・リポジトリの設定」

12.2.1 配布管理

継続的インテグレーションに含まれるすべてのプロジェクトで、そのPOMのdistributionManagementセクションを指定する必要があります。このセクションは、ビルド・プロセスの最後にアーティファクトがどこにデプロイされるか、つまりどのリポジトリ(ローカルまたはリモート)にデプロイされるかをMavenに指示します。このマニュアルの例では、Archivaリポジトリを使用します。アーティファクトをリポジトリにデプロイすると、それらを他のプロジェクトで依存関係として使用できるようになります。

distributionManagementセクションを定義して、スナップショットをデプロイするリポジトリを示し、リリースする必要があります。distributionManagement構成は、第8章で説明しているように、Oracle共通のPOMなど、すべてのプロジェクトで共有される共通継承POMに配置することをお薦めします。

次に、distributionManagement構成の例を示します。

<distributionManagement>
<repository>
<uniqueVersion>false</uniqueVersion>
<id>releases</id>
<name>Releases</name>
<url>http://server:port/archiva/repository/releases/</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<uniqueVersion>true</uniqueVersion>
<id>snapshots</id>
<name>Snapshots</name>
<url>http://server:port/archiva/repository/snapshots</url>
<layout>default</layout>
</snapshotRepository>
</distributionManagement>

12.2.2 スナップショット・リポジトリの設定

Mavenがリポジトリにアクセスする方法とそのタイミングを管理する重要な設定があります。

更新ポリシー: これは、Mavenがリモート・リポジトリに対して、すでにローカル・リポジトリにあるアーティファクトの更新を確認する頻度を制御します。Hudsonのsettings.xmlで、updatePolicyをalwaysとして使用するようにスナップショット・リポジトリを構成します。updatePolicyの設定は、各自の開発システムに影響します。デフォルト値はdailyです。Hudsonで変更が行われたときにその変更を統合する場合は、それらのupdatePolicyを適宜に変更する必要があります。依存性は、警告なしで突然変更される場合があります。継続的インテグレーション・システムで、不具合の発生を削減するために適所で十分なテストを行う必要がある間、開発時の最新のスナップショットによっては、さらに問題が発生する可能性があります。このような例の1つとしてAPIの変更があげられます。

すべてのプロジェクトのスナップショットの依存性を最新の状態にして、チェックインの前に、デプロイされているコードベースの現在の状態がローカル・ビルドに反映されるようにする必要があります。

サーバー資格証明: これは、リモート・リポジトリへのアクセスに必要な資格証明をMavenに通知します。一般的にMavenリポジトリでは、たとえば新規アーティファクトの公開などのリポジトリの変更を行えるようになる前に認証を行う必要があります。Archivaゲスト・ユーザーにグローバル・アップロード権限を付与する場合を除いて(これはお薦めできません)、serversセクションにスナップショット・リポジトリの正しい資格証明を指定する必要があります。スナップショット・リポジトリのアップロード権限を持つ一意のHudsonユーザーを設定する必要があります。ユーザーおよびロール構成の詳細は、第4章を参照してください。

パスワード値にはMavenのパスワード暗号化を使用します。パスワード暗号化に関するMavenのマニュアルは、http://maven.apache.org/guides/mini/guide-encryption.htmlで参照できます。

次に、Hudsonユーザー向けのsettings.xml構成の例を示します。

<settings>
...
<servers>
...
<server>
<id>snapshots</id>
<username>hudson</username>
<password>{COQLCE6DU6GtcS5P=}</password>
</server>
...
</servers>
...
</settings>

12.3 Hudsonを使用したビルドの自動化

この項では、Hudsonでのビルド・ジョブの設定方法を説明します。Mavenプロジェクトのビルドに使用できる様々なオプションがあります。この項では、Oracleによって推奨されているアプローチについて説明します。

先に進む前に、第6章の説明に従って、Hudsonが構成済であることを確認してください。

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

- 12.3.1項「Hudsonジョブを作成してMavenプロジェクトをビルドする方法」

- 12.3.2項「Hudsonビルドのトリガー」

- 12.3.3項「Hudsonを使用した複数モジュールのMavenビルドの管理」

12.3.1 Hudsonジョブを作成してMavenプロジェクトをビルドする方法

基本的なMaven Hudsonジョブを作成するには:

1. Hudson Webインタフェースを開き、必要に応じてログインします。

2. 新しいジョブを作成します。

1. 右側のメニューから「New Job」を選択します。

2. 一意の名前を指定し、「Build a free-style software project」を選択します。

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

3. ソース・コード管理を構成します。
SSH公開鍵および秘密鍵の構成を含め、Subversionサーバーの構成が完了していることを確認します。

1. 「Source Code Management」で、「Subversion」を選択します。

2. プロジェクト・ディレクトリのリポジトリURLを指定します。たとえば、svn+ssh://subversion-server/ciroot/subversion/repository/trunk/projects/my-projectなどです。

注意:

この例では、SSHを使用してSubversionにアクセスするsvn+ssh URLを使用しています。別のプロトコルを使用している場合、構成に必要なステップが多少異なることがあります。

HudsonによってURLの検証が試行され、次のようなエラー・メッセージが返される場合があります。

Unable to access svn+ssh://hostname/ciroot/subversion/repository/trunk :
svn: E200015: authentication cancelled(show details)
(Maybe you need to enter credential?)

このようなエラー・メッセージが表示された場合は、次の手順を実行します。

1. メッセージの「enter credentials」をクリックします。

2. 「SSH public key authentication (svn+ssh)」を選択します。

3. ユーザー名を入力します。

4. 必要に応じて、SSH秘密鍵パス・フレーズを入力します。

5. Hudsonファイル・システムの秘密鍵ファイルを選択します。形式は~/.ssh/id_rsaです。

4. Mavenビルド・ステップを追加します。

1. 「Build」セクションで、「Add Build Step」ドロップダウン・メニューから「Invoke Maven 3」を選択します。

2. 「Maven 3 home」を選択します。必要なゴールおよびプロパティを適切なテキスト・フィールドに追加します。

3. SNAPSHOT継続的インテグレーション・ビルド環境が整っている場合は、クリーン・デプロイを実行するようにゴールを構成します。

4. 必要に応じて、Hudsonの構成時に、「Advanced」設定を開き、Settingsエントリが、Hudson Webインタフェースで作成したMaven設定を指していることを確認します。

5. 構成を保存します。
ページの下部にある「保存」をクリックします。

12.3.2 Hudsonビルドのトリガー

Hudsonでは、Hudsonでの継続的インテグレーション・ビルドのトリガーを管理する方法を多数提供しています。これらには、手動および自動によるトリガーが含まれています。手動でビルドを開始するオプションは、あらゆるジョブに対して常に使用可能です。自動トリガーを選択した場合は、プロジェクトの構造、ソース・コードの場所、分岐の有無などの要因を考慮します。

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

- 12.3.2.1項「手動によるビルドのトリガー」

- 12.3.2.2項「Subversionリポジトリによるトリガー」

- 12.3.2.3項「スケジュール・ベースのトリガー」

- 12.3.2.4項「Hudsonの依存性変更によるトリガー」

- 12.3.2.5項「Maven SNAPSHOT変更」

ビルドのトリガー方法に関係なく、ジョブは保留ジョブ・キューに追加され、リソースが使用可能になったときに実行されます。

12.3.2.1 手動によるビルドのトリガー

すべてのジョブをユーザー・インタフェースから「Build Now」リンクを使用して開始できます。

12.3.2.2 Subversionリポジトリによるトリガー

このタイプのビルド・トリガーは、正常な継続的インテグレーション・ビルドの構築に不可欠です。プロジェクト・ソースに対する変更が行われると、Hudsonは関連するHudsonジョブのビルドをトリガーします。トリガーは、関連するSubversion URLの変更を定期的に確認することによって、これを実行します。

このトリガーを有効にするには、「Poll SCM」オプションを選択します。次に、Hudsonがリポジトリのポーリングに使用するスケジュールを決定するcron式を指定する必要があります。

12.3.2.3 スケジュール・ベースのトリガー

ジョブ・タイプによっては、スケジュールに基づいてこれらをトリガーできます。長期間実行しているシステム・インテグレーション・テストは、定期的に実行するビルドの一例であり、これは、テスト・ソースが変更されるたびに実行するビルドとは対照的です。

スケジュール・ベースのトリガーは、Poll SCMトリガーと非常によく似たcron式を使用して構成します。

12.3.2.4 Hudsonの依存性変更によるトリガー

小さなプロジェクトに複数のビルドが含まれ、これらのビルドで、相互に依存性を持つ一意のアーティファクトが作成される場合があります。トリガー・タイプの結果としてHudsonでアーティファクトを再ビルドする場合は、インテグレーションが引き続き有効になるように、依存するアーティファクトもビルドおよびテストする必要があります。このHudsonサーバーでビルドされた依存関係が正常に完成すると、Hudsonは自動的にこれらの関係を認識し、ビルドをトリガーします。このトリガーが機能するには、依存性で、ビルド後のアクション「Notify that Maven dependencies have been updated by Maven 3 integration」を有効にすることも必要です。

12.3.2.5 Maven SNAPSHOT変更

同時に開発され、共通のMavenリポジトリでスナップショットとして管理されている依存関係が存在する場合、Hudsonインスタンスでこれらを管理する必要があります。この方法が実用的でない場合、SNAPSHOT依存性トリガーを使用して、このような依存性における変更についてMavenリポジトリを監視できます。更新されたSNAPSHOT依存性が検出されると、ビルドがトリガーされ、インテグレーションのために新しい依存関係がダウンロードされます。

このトリガーでは、cron式を使用してポーリング間隔も構成します。

12.3.3 Hudsonを使用した複数モジュールのMavenビルドの管理

ビルド依存性を正しく管理するには、各プロジェクトを別々のHudsonビルドとして追加し、依存性トリガーを手動で構成するか、または、複数モジュールのMaven POMを親Hudsonジョブとして構成します。複数モジュールのソリューションでは、手動で依存性を結びつける際の誤りを減らすことができます。また、Maven構成での依存性の変更にあわせて最新の状態に保つことができます。

複数モジュールのビルドの構成は、通常のプロジェクトの構成と同じです。コンポーネント・プロジェクト・ビルドの結果を調べるために、Hudsonでは「Maven 3 Build Information」リンクのビルド結果ページにタブが用意されています。ページの一番上にある「Modules」タブに、コンポーネント・ビルドの結果の要約が表示されます。

任意のサブプロジェクト・ビルドのログを確認するには、「Console Log」リンクを使用します。すべてのプロジェクトおよびサブプロジェクト・ビルドが実行順にログに記録されます。

12.4 ビルドの監視

ビルドが中断した場合に適切なパーティに通知を送信するように、Hudsonを構成する必要があります。継続的インテグレーション・システムでは、変更でビルドおよびテスト・プロセスが中断されないようにする必要があります。このようなことが発生した場合は、中断に関する通知を受信して、可能なかぎり迅速に問題に対処する必要があります。Hudsonでは、各ユーザーを一意のユーザーとして登録します。Hudsonユーザー名は、通常コミットに使用するSubversionユーザー名と一致している必要があります。Hudsonはこの名前に基づいて、適切な連絡先電子メールを検索し、通知を送信します。

一般的な電子メール通知構成は、「Manage Hudson」→「Configure System」→「E-mail Notification」で参照できます。

また、ユーザー管理のいくつかのフォームが有効になっていることを確認する必要もあります。これは、「Configure System」パネルから「Enable Security」を選択することで実行できます。ユーザー管理には多数の選択肢があり、LDAPなど、他の大多数の一般的なソリューションをサポートする追加のサード・パーティ製プラグインがあります。最適なオプションは、「Hudson's own user database」を使用することです。この選択肢は「Access Control」セクションから選択します。特定のユーザーおよびグループに対する許可を制限するための追加オプションがあります。

新規ユーザーを追加する場合は、Hudsonホーム・ページの一番上にある「sign up」リンクに従い、必要な情報を入力するだけで追加できます。ユーザー名は対応するSubversionユーザー名と一致している必要があります。

12.4.1 トリガーされたビルドのフォロー・アップ

通常、継続的ビルド・システムが正常に保持され、有効な結果をもたらしていることを確認するには、自動通知で十分です。ただし、状況によっては、追加の監視や、システムを稼働状態に戻すための調整が必要になる可能性があります。このような問題の追跡、広範な問題のソリューションの調整、システム自体が疑わしい場合のトラブルシューティングを実行するビルド・コーディネータを指名しておくことが得策です。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。