Mavenはフレームワーク、Antはツールボックスです
Mavenは組み立て済みのロードカーですが、Antは自動車部品のセットです。Antを使用すると、自分の車を作成する必要がありますが、少なくともオフロード走行を行う必要がある場合は、適切なタイプの車を作成できます。
別の言い方をすれば、Mavenはフレームワークであり、Antはツールボックスです。フレームワークの範囲内での作業に満足している場合は、Mavenで十分です。私にとっての問題は、私がフレームワークの境界にぶつかり続けて、それが私を出させないことでした。
XMLの冗長性
tobrienはMavenについてよく知っている人で、私は彼が2つの製品の非常に優れた、正直な比較を提供したと思います。彼は単純なMaven pom.xmlを単純なAntビルドファイルと比較し、Mavenプロジェクトがいかに複雑になるかについて言及しました。単純な実際のプロジェクトで見られる可能性が高いいくつかのファイルの比較を見てみる価値があると思います。以下のファイルは、マルチモジュールビルドの単一モジュールを表しています。
まず、Mavenファイル：
<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/maven-4_0_0.xsd">
<parent>
<groupId>com.mycompany</groupId>
<artifactId>app-parent</artifactId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>persist</artifactId>
<name>Persistence Layer</name>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>common</artifactId>
<scope>compile</scope>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>domain</artifactId>
<scope>provided</scope>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernate.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>${commons-lang.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${spring.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
<version>2.2.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
<classifier>jdk15</classifier>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>${commons-dbcp.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>${oracle-jdbc.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymock</artifactId>
<version>${easymock.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
そして同等のAntファイル：
<project name="persist" >
<import file="../build/common-build.xml" />
<path id="compile.classpath.main">
<pathelement location="${common.jar}" />
<pathelement location="${domain.jar}" />
<pathelement location="${hibernate.jar}" />
<pathelement location="${commons-lang.jar}" />
<pathelement location="${spring.jar}" />
</path>
<path id="compile.classpath.test">
<pathelement location="${classes.dir.main}" />
<pathelement location="${testng.jar}" />
<pathelement location="${dbunit.jar}" />
<pathelement location="${easymock.jar}" />
<pathelement location="${commons-dbcp.jar}" />
<pathelement location="${oracle-jdbc.jar}" />
<path refid="compile.classpath.main" />
</path>
<path id="runtime.classpath.test">
<pathelement location="${classes.dir.test}" />
<path refid="compile.classpath.test" />
</path>
</project>
tobrienは彼の例を使用して、Mavenに組み込みの規則があることを示しましたが、必ずしもXMLの記述が少なくなるとは限りません。私はその反対が真実であることを発見しました。pom.xmlは、build.xmlの3倍の長さであり、規則から逸脱することはありません。実際、私のMavenの例は、プラグインの構成に必要な追加の54行なしで示されています。そのpom.xmlは単純なプロジェクト用です。追加の要件を追加し始めると、XMLは実際に大幅に成長し始めます。これは、多くのプロジェクトでは通常のことです。
しかし、あなたはAntに何をすべきかを伝えなければなりません
上記の私のAntの例はもちろん完全ではありません。クリーンアップ、コンパイル、テストなどに使用するターゲットを定義する必要があります。これらは、マルチモジュールプロジェクトのすべてのモジュールによってインポートされる共通のビルドファイルで定義されます。これは、Mavenでは宣言型であるのに対し、Antでこれらすべてを明示的に記述する必要があるという点に私を導きます。
確かに、これらのAntターゲットを明示的に記述する必要がない場合は、時間を節約できます。しかし、どのくらいの時間ですか？現在使用している一般的なビルドファイルは、5年前に作成したもので、それ以降は少しだけ改良されています。Mavenでの2年間の実験の後、古いAntビルドファイルをクローゼットから引き出して、ほこりを払い、作業に戻しました。私にとって、Antに明確に何をすべきかを伝える必要があるため、5年間で1週間足らずでした。
複雑
次に触れておきたい主な違いは、複雑さとそれがもたらす実際の効果の違いです。Mavenは、ビルドプロセスの作成と管理を担当する開発者の作業負荷を軽減することを目的として構築されました。これを行うには、複雑にする必要があります。残念ながら、その複雑さは意図した目標を否定する傾向があります。
Antと比較すると、Mavenプロジェクトのビルド担当者はより多くの時間を費やします。
- ドキュメントの読み方：Mavenには、学習する必要のあるドキュメントがはるかに多いため、ドキュメントがはるかに多くなります。
- チームメンバーの教育：自分で答えを見つけようとするよりも、知っている人に質問する方が簡単だと感じます。
- ビルドのトラブルシューティング：Mavenは、Antよりも信頼性が低く、特に非コアプラグインです。また、Mavenビルドは繰り返し可能ではありません。プラグインのスナップショットバージョンに依存している可能性が高い場合、何も変更しなくてもビルドが壊れる可能性があります。
- Mavenプラグインの作成：プラグインは通常、特定のタスクを念頭に置いて作成されます。たとえば、webstartバンドルを作成すると、プラグインを他のタスクに再利用したり、組み合わせて目標を達成したりすることが難しくなります。そのため、既存のプラグインセットのギャップを回避するには、独自のプラグインを作成する必要がある場合があります。
対照的に：
- Antのドキュメントは簡潔で包括的で、すべて1か所にあります。
- Antは単純です。Antを学習しようとする新しい開発者は、知っておく必要がある残りの部分を理解できるようにするために、いくつかの単純な概念（ターゲット、タスク、依存関係、プロパティ）を理解するだけで済みます。
- Antは信頼できます。Antはすでに機能しているため、過去数年間、Antのリリースはそれほど多くありません。
- Antビルドは通常、オンラインリポジトリ、実験的なサードパーティプラグインなどの外部依存関係なしで作成されるため、反復可能です。
- Antは包括的です。ツールボックスであるため、ツールを組み合わせてほぼすべてのタスクを実行できます。独自のカスタムタスクを作成する必要がある場合は、非常に簡単です。
親しみやすさ
もう1つの違いは、親しみやすさの違いです。新しい開発者は、速度を上げるために常に時間を必要とします。既存の製品に精通していることがその点で役立ち、MavenサポーターはこれがMavenの利点であると正しく主張します。もちろん、Antの柔軟性は、好きな規則を作成できることを意味します。したがって、私が使用する規則は、ソースファイルをsrc / main / javaというディレクトリ名に置くことです。コンパイルしたクラスは、target / classesという名前のディレクトリに移動します。おなじみの音はそれではありません。
Mavenで使用されるディレクトリ構造が好きです。それは理にかなっていると思います。また、ビルドライフサイクル。したがって、私はAntビルドで同じ規則を使用します。それが理にかなっているだけでなく、以前にMavenを使用したことがある人なら誰でも知っているからです。