Apache MavenによるJavaプロジェクトポータビリティの向上

ソフトウェア開発のライフサイクル全体を通じてプロジェクトのポータビリティを維持する

開発環境から本番環境へ移行するときなど、ビルド環境に応じてJavaプロジェクトに修正を加えなくてはならないときがあります。そういった負荷を軽減するために、プロジェクトのポータビリティを判断し、Mavenによってそのポータビリティをどう高めることができるかを説明します。

はじめに

　皆さんのソフトウェア開発のライフサイクルが私のものと似ているとすれば、ライフサイクルはそれぞれ独自のプロジェクト構成を必要とする複数のフェーズに分かれていて、そのためにこれらの異なるフェーズを経てプロジェクトを進行させることが難しくなっているかもしれません。例えば、開発フェーズではローカルのデータベースに接続することを要求しているのに、統合テスト環境のデータベースはローカルではない場合があります。そして、テストデータベースは必ずと言っていいほど本番データベースと異なります（そうであることを願います）。

　そこで役立つのが、Apache Maven 2です。Apache Maven 2では、1つのポータブルなプロジェクトオブジェクトモデル（Project Object Model：POM）を作成できるので、統合テスト担当者や開発チームはプロジェクトに変更を加える作業から解放されます。Mavenは、プロジェクト構造の適用、プロジェクトの依存性管理、プロジェクトのカプセル化、組み込みサイトの生成、さらにSubversionやContinuumなどのツールとのシンプルな統合を実現することに加え、柔軟性を維持しながらポータビリティをできるだけ単純にすることを目指しています。そのために、Mavenにはビルドのポータビリティ問題に対応するための2つの主要ツールとして、プロパティとプロファイルが用意されています（Javaビルドのポータビリティの歴史については、「補足説明1　MakeからMavenへ」を参照してください）。

補足説明1　MakeからMavenへ

　プロジェクトのポータビリティを一番適切に表現しているのは、「プロジェクトをどれくらい簡単に別のマシンに移してビルドすることができるか」という質問と、この質問に対する答えです。つまり、正しい成果物を生成するビルド環境を構築するのにどのくらいの（そしてどのような種類の）修正を加えなければならないかということです。仮想マシン以前は、コードを実行する各タイプのマシンでコードをコンパイルしなければなりませんでした。
　Javaにはこの問題はありませんが、他の問題があります。心配しなければならないのは、コンパイルのポータビリティ問題（バイト順序や命令セットの違いなど）ではなく、ビルドプロセスそのもののポータビリティ問題だけです。
　従来のビルドツールは増分変更によってこの問題に取り組みました。Makeは、シェルスクリプトとは対照的に、その一貫性のあるほぼ抽象的な構文により、従来のメソッドよりもポータビリティに優れていました。ただし、マシン固有のマシンツールに依存しているため、最新の標準ではほとんどポータビリティはありません。Antは、Makeのマシンポータビリティ問題を解決するために作成されたものですが、独自の問題を抱えています。Antのタスクにはマシン間のポータビリティはありましたが、タスクのユーザーは必要なタスクが含まれているjarを手動でダウンロードしてインストールしなければなりませんでした。
　Mavenは、Antのマシンポータビリティ性を拡張して、オンラインリポジトリを通じたネットワークポータビリティを追加しました。ビルドに特定のゴールがなくても問題ありません。Mavenが自動的にダウンロードしてインストールしてくれます。必要なのは、プロジェクトを定義するためのプロジェクトオブジェクトモデル（Project Object Model：POM）だけです。とは言え、問題はまだ残っています。Mavenではビルドツールのポータビリティは大幅に改善されましたが、プロジェクトそのもののポータビリティはまだ解決されていません。
　現在では、ポータビリティ問題の大部分はプロジェクト設計の領域で取り扱われています。この傾向をよく表しているのが、さまざまなコンポーネントを外部化するという試みです。例えば、特定のURL（JDBCおよびHTTP）の外部化、ストリングの共通化（少なくとも.propertiesファイル内のストリング）、ネーミングサービス（JNDIなど）の使用などがあります。さらに、依存性を外部で定義してIoCコンテナ（SpringやPlexusなど）を介して注入するという手法もあります。しかし、こうしたやり方は、他のファイルに負担を転嫁しているだけではないでしょうか。もちろんそうですが、これらのファイルを利用することでコードの処理/生成を回避できるようになり、ポータビリティ問題は大幅に単純化されています。

プロパティとプロファイル

　MavenのプロパティはAntのプロパティとまったく同じです。値のプレースホルダであり、事前設定済みのものもあります。4つの異なるスタイルのプロパティを利用することができます。

1. env.X
変数にプレフィクス「env」を付けると、シェルの環境変数が返されます。例えば、${env.PATH}を指定すると$path（Windowsでは%PATH%）環境変数が返されます。
2. project.x
POMでドット（.）付きのパスを指定すると対応する要素の値が返されます。例えば、<project><version>1.0</version></project>にアクセスするには、${project.version}を指定します。
3. システムプロパティ
${java.home}など、java.lang.System.getProperties()を介してアクセスできるプロパティはすべて、POMプロパティとして利用することができます（POMをデバッグする近道については、「補足説明2　プロパティ値を表示する」を参照してください）。
4. x
<properties />要素または外部ファイル内に設定されている値は、${someVar}として使用することができます。

　Mavenでは、プロパティと共に、ビルドプロファイルの概念も追加されました。これは、環境要因に基づいてPOMに全面的な変更を加えるためのソリューションです。Antベースのビルドにおける共通のプラクティスは、複数の環境にまたがってプロジェクトをビルドするための方法をプロパティとして表現することでした。Mavenでは、問題を単純化するために、このような手続き的アプローチを排除して、代わりに「あるプロファイルがアクティブの場合には、これらの設定を使う」という宣言を用います。プロファイルをアクティブにするには、次のような方法があります。

• アクティベーション
例えば、「JDK1.4でコンパイルする場合にこのプロファイルアクティブにする」などと定義します。
• コマンドライン
引数-P <profileID>を使用します。
• アクティブプロファイル
「settings.xml」ファイル内のある要素に含まれている<activeProfile>profileID</activeProfile>要素を使用します。

　プロファイルの詳細については、Mavenのサイトのガイドを参照することをお勧めします。

補足説明2　プロパティ値を表示する

　特定のパラメータの値をデバッグする必要がある場合は、次のように「pom.xml」ファイル内でAntプラグインを構成します。

<project>
  ....
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-antrun-plugin</artifactId>
        <configuration>
          <tasks>
            <echo>${project.build.directory}</echo>
          </tasks>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>

　その後、次のようにしてこのプラグインを実行します。

mvn antrun:run

　Antプラグインは文字列値を返します。