プロファイルによる環境的なポータビリティ
原則として、環境ごとに1つのプロファイルを作成するようにしてください。ビルドの環境タイプが5つを超える場合を除き、プロファイルはPOMに入れることをお勧めします。こうしておけば、コマンドラインで-P引数を指定して必要なプロファイルをアクティブにすることができます。次のようにhelpプラグインを使ってどのプロファイルが現在アクティブであるかをテストすることができます。
mvn help:active-profiles
環境の変更は「settings.xml」ファイルを利用すればもっと簡単になります。サンプルプロジェクトには、env-dev、env-test、env-prodの3つのプロファイルが入っています。env-testプロファイルをテスト環境で常にアクティブしておきたい場合は、次のようにその環境の「settings.xml」ファイルにactiveProfileを追加します。
<settings> ... <activeProfiles> <activeProfile>env-test</activeProfile> </activeProfiles> </settings>
すべての環境別プロジェクトで、テストプロファイルにenv-testという名前を付けます。このプロファイルがない場合は、activeProfile行が無視されるだけです。サンプルプロジェクトには「settings.xml」ファイルが入っているので、自由に試してみてください。
プロファイルの増加に対応する
プロファイルがもっと増えた場合はどうしたらよいでしょうか。プロジェクトによっては、複数のクライアント、場合によっては数百ものクライアントに合わせて、微妙なビルド変更が必要になることがあります。この場合に実行すべきことは、必要なビルド時にコピーできる「profiles.xml」ファイルの作成です。「profiles.xml」ファイルは「pom.xml」のprofiles要素とまったく同じで、1つ以上のprofile要素を含みます。例えば、次のような1つ目のクライアント向けのプロファイルがあるとします。
<profiles> <profile> <id>client-0001</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <!-- The client loves blue --> <css.pref>blue.css</css.pref> <!-- They want standard pkg --> <module>default</module> </properties> </profile> </profiles>
「profiles.xml」ごとに1つのプロファイルを作成し、それをactiveByDefaultにします。この存在そのものによって、プロファイルがビルドで利用されることが保証されます。前述の「profiles.xml」ファイルが基本ベースディレクトリ内にある場合にhelp:active-profilesを実行すると、以下が出力されます。
The following profiles are active: - client-0001 (source: profiles.xml)
プロパティではなくプロファイルを使う
ここでお勧めする簡単な作業は、プロファイルが1つのプロパティからのみ成り立っている場合でも、コマンドラインプロパティを渡すのではなく、環境プロファイルを作成することです。この背後にある論理は単純です。例えば、環境に対し次のようなプロファイルを作成するとします。
<profiles> <profile> <id>env-test</id> <properties> <install.location>/testbox/app</install.location> </properties> </profile> </profiles>
この場合、コマンドラインでアクティベーションを行うには次のように指定します。
mvn install -P env-test
次のように指定してはなりません。
mvn install -Dinstall.location=/user/local/test
プロパティをもう1つ追加する必要がある場合を想像しましょう。手動によるプロパティの設定は長くなりますが、プロファイル化したPOMコマンドラインは固定されているので、将来的にプロパティをいくつ追加しても変わりません。
mvn install -Dinstall.location=/user/local/test -Dnew.prop=true
これは、Continuumのような継続的な統合サーバーを使う場合に重要になります。
プロジェクト構造の問題を回避する
maven-antrun-pluginを介して大量のAntコードをPOMに注入することは、非ポータブルなプロジェクトでよく見られる光景です。一般に他のMavenプラグインでは要件を満たさないことが分かったら、まずプロジェクト構造を調べることが賢明です。
プロジェクト構造を調べたところ、Mavenの非ポータビリティのもう1つの厄介な面が見つかりました。プロジェクトのネストです。例えば、次のようにEARにWARがネストされているとします。
myEar
pom.xml
META-INF/application.xml
myWar
src/MyServlet.java
WEB-INF/web.xml
Maven以前は、これはWARから成るプロジェクトを1つのEARでセットアップする一般的な方法でした。Antは、構造をまったく強要しない点が受け入れられていました。このような構造をMavenに持ち込み、組み込みのAntやmaven-assembly-pluginを使ってプロジェクトをビルドしようとする人もいます。例えば、1人のユーザーに対してこのようなプロジェクトを作成したとします。その後、異なるEAR構成を必要とする新しいユーザーが出てきました。WARは論理的には別個のプロジェクトですが、これを別のEARに移すのは非常に難しいことがわかっています。このプロジェクトを新しいユーザーに移植できる可能性は限られています。
これは、Mavenの非標準のプロジェクト構造を強制的にMavenのフレームワークにしようとしている例です。こうした特定の例では、次のようにEARとWARを別々のプロジェクトに分ける必要があります。
myEar
pom.xml
src/main/resources/META-INF/application.xml
myWar
pom.xml
src/main
java/MyServlet.java
resources/WEB-INF/web.xml
新しいユーザーに新しいEARを割り当てることは、何の問題もありません。myWarに対する依存性を持つ新しいEARプロジェクトを追加するだけです。心配無用です。覚えておけば役に立つでしょう。
