TheNEXUS

1.7. Maven と Ant の比較

この本の著者は Apache Ant と Apache Maven の間に確執を作ることに興味はありませんが、ほとんどの組織が二つの標準的なソリューションの間で決断しなければならないという事実も承知しています。 Apache AntとApache Mavenです。 このセクションでは、ツールを比較対照します。

Ant はビルドプロセスに優れており、ターゲットと依存関係を持つ make の後にモデル化されたビルドシステムです。 各ターゲットは XML でコード化された命令のセットで構成されています。 copyタスク、javacタスク、jarタスクがある。 Antを使うとき、Antにコンパイルとパッケージングのための具体的な指示を与えることになります。 次のシンプルなbuild.xmlファイルの例を見てください。

A Simple Ant build.xml file.

<project name="my-project" default="dist" basedir="."> <description> simple example build file </description> <!-- set global properties for this build --> <property name="src" location="src/main/java"/> <property name="build" location="target/classes"/> <property name="dist" location="target"/> <target name="init"> <!-- Create the time stamp --> <tstamp/> <!-- Create the build directory structure used by compile --> <mkdir dir="${build}"/> </target> <target name="compile" depends="init" description="compile the source " > <!-- Compile the java code from ${src} into ${build} --> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile" description="generate the distribution" > <!-- Create the distribution directory --> <mkdir dir="${dist}/lib"/> <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file --> <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/> </target> <target name="clean" description="clean up" > <!-- Delete the ${build} and ${dist} directory trees --> <delete dir="${build}"/> <delete dir="${dist}"/> </target></project>

この単純なAntの例では、Antexactlyに何をすべきかを伝えなければならないかが分かります。 src/main/java ディレクトリのソースを target/classes ディレクトリにコンパイルする javac タスクが含まれるコンパイル目標があります。 ソースがどこにあるか、バイトコードがどこに格納されるか、 そして、どのようにJARファイルにまとめるかを正確にAntに伝えなければなりません。 最近の開発では、Antをより手続き的でなくするのに役立つものがありますが、開発者のAntの経験は、XMLで書かれた手続き的な言語をコーディングすることです。 Mavenでは、あるJavaソースからJARファイルを作成するために、簡単なpom.xmlを作成し、ソースコードを${basedir}/src/main/javaに置き、コマンドラインからmvn installを実行するだけで良いのです。 A Simple Ant build.xml file にあるシンプルな Ant ファイルと同じ結果を得る Maven pom.xml の例は、A Sample Maven pom.xml.

A Sample Maven pom.xml.

A Simple Ant build.xml file にあります。

<project> <modelVersion>4.0.0</modelVersion> <groupId>org.sonatype.mavenbook</groupId> <artifactId>my-project</artifactId> <version>1.0</version></project>

これだけあれば、pom.xmlは完成です。 コマンド ラインから mvn install を実行すると、リソースの処理、ソースのコンパイル、ユニテストの実行、JAR の作成、および JAR を他のプロジェクトで再利用できるようにローカル リポジトリにインストールされます。 このファイルには、JavaDoc へのリンクとソース コードに関するいくつかのレポートが含まれています。

確かに、これはいくつかのソース コードと単純な JAR を生成する以上のものを含まない、可能な限り最も単純なサンプル プロジェクトです。 これは、Maven の規約に密接に従ったプロジェクトであり、依存関係やカスタマイズを必要としません。 もし、動作のカスタマイズを開始したい場合、pom.xmlは大きくなり、最も大きなプロジェクトでは、非常に複雑なMaven POMのコレクションを見ることができ、そこには多くのプラグインのカスタマイズと依存性の宣言が含まれています。 しかし、プロジェクトのPOMファイルがより実質的になったとしても、Antを使用した同規模のプロジェクトのビルドファイルとは、全く異なる種類の情報を保持しています。 MavenのPOMは、宣言を含んでいます。 「これはJARプロジェクトです」、「ソースコードはsrc/main/javaにあります」。 Antのビルドファイルは、「これはプロジェクトです」、「ソースはsrc/main/javaにあります」、「このディレクトリに対してjavacを実行します」、「結果をtarget/classesに入れます」、「…からJARを作成します」など、明示的に指示を含んでいます。 Ant が処理について明示的でなければならないのに対し、Maven には、ソースコードがどこにあり、どのように処理されるべきかを知っている「組み込み」のものがあります。

  • Apache Ant

    • Ant には一般的なプロジェクトディレクトリ構造やデフォルト動作などの正式な規則がありません。 ソースがどこにあり、出力がどこにあるのかを正確にAntに伝えなければなりません。 非公式な慣習は時間の経過とともに現れていますが、 製品として成文化されてはいません。
    • Ant は手続き的です。 Ant にいつ何をするのか、正確に伝えなければなりません。 コンパイルして、コピーして、圧縮してと指示しなければなりません。 あなたはゴールとゴールの依存関係を定義しなければなりません。
  • Apache Maven

    • Maven には慣例があります。 慣習に従ったので、ソース コードがどこにあるかがわかります。 Maven のコンパイラー プラグインはバイトコードを target/classes に配置し、JAR ファイルを target に生成します。 pom.xml ファイルを作成し、ソースをデフォルトのディレクトリに置くだけでよかったのです。
    • Maven にはライフサイクルがあり、mvn install を実行したときに呼び出されました。 このコマンドは、インストール ライフサイクル フェーズに到達するまで、一連の連続したライフサイクル フェーズを実行するように Maven に指示しました。 ライフサイクルを通じてのこの旅の副作用として、Maven はコンパイルと JAR の作成のようなことを行う多くのデフォルトのプラグイン目標を実行しました。 ユニット テストを書いて実行したい場合、必要なことは、テストを書き、${basedir}/src/test/java に置き、TestNG または JUnit のいずれかにテスト スコープの依存関係を追加して、mvn test を実行することだけです。 もし、JAR ではなく Web アプリケーションをデプロイしたかったら、プロジェクトの種類を war に変更し、docroot を ${basedir}/src/main/webapp に置くだけでよいでしょう。 もちろん、Antでもこのようなことはできますが、ゼロから指示を書くことになります。 Antでは、まず、JUnitのJARファイルがどこにあるべきかを見つけなければなりません。 そして、JUnitJARファイルを含むクラスパスを作成する必要があります。

      Antlibs や Ivy のようなサポート技術がない場合 (これらのサポート技術があっても)、Ant はカスタム手続きビルドのような感じがあります。 Mavenの想定される規約を遵守するプロジェクトにおける効率的なMaven POMのセットは、Antの代替と比較して驚くほど少ないXMLです。 Mavenのもう一つの利点は、広く共有されたMavenプラグインに依存することです。 誰もがユニットテストのために Maven Surefire プラグインを使用し、誰かが新しいユニットテストフレームワークのサポートを追加した場合、プロジェクトの POM で特定の Maven プラグインのバージョンを増加させるだけで、自分のビルドで新しい機能を獲得することができます。 現在のビルドが高度にカスタマイズされたプロセスを含んでいる場合、または、Maven標準に適応できない特定の方法で特定のプロセスを完了するためにいくつかのAntスクリプトを書いた場合、これらのスクリプトはまだMavenで使用することができます。 Antは、Mavenのコアプラグインとして提供されています。 また、Mavenプロジェクトは、Mavenプロジェクトのライフサイクルの中でAntスクリプトを実行するように設定することができます。

Leave a Reply