Maven ist ein Framework, Ant ist eine Toolbox
Maven ist ein vorgefertigtes Straßenauto, während Ant ein Satz von Autoteilen ist. Mit Ant müssen Sie Ihr eigenes Auto bauen, aber zumindest wenn Sie im Gelände fahren müssen, können Sie den richtigen Autotyp bauen.
Anders ausgedrückt, Maven ist ein Framework, während Ant eine Toolbox ist. Wenn Sie damit zufrieden sind, innerhalb der Grenzen des Frameworks zu arbeiten, ist Maven in Ordnung. Das Problem für mich war, dass ich immer wieder an die Grenzen des Frameworks stieß und es mich nicht rausließ.
XML-Ausführlichkeit
tobrien ist ein Typ, der viel über Maven weiß, und ich denke, er hat einen sehr guten, ehrlichen Vergleich der beiden Produkte geliefert. Er verglich eine einfache Maven-Datei pom.xml mit einer einfachen Ant-Build-Datei und erwähnte, wie Maven-Projekte komplexer werden können. Ich denke, es lohnt sich, einen Vergleich einiger Dateien anzuschauen, die Sie in einem einfachen realen Projekt eher sehen. Die folgenden Dateien stellen ein einzelnes Modul in einem Build mit mehreren Modulen dar.
Zuerst die Maven-Datei:
<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>
Und die entsprechende Ant-Datei:
<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 hat sein Beispiel verwendet, um zu zeigen, dass Maven integrierte Konventionen hat, aber das bedeutet nicht unbedingt, dass Sie am Ende weniger XML schreiben. Ich habe das Gegenteil festgestellt. Die pom.xml ist dreimal länger als die build.xml und das ohne von den Konventionen abzuweichen. Tatsächlich wird mein Maven-Beispiel ohne zusätzliche 54 Zeilen angezeigt, die zum Konfigurieren von Plugins erforderlich waren. Diese pom.xml ist für ein einfaches Projekt. Das XML wächst wirklich erheblich, wenn Sie zusätzliche Anforderungen hinzufügen, was für viele Projekte nicht ungewöhnlich ist.
Aber du musst Ant sagen, was zu tun ist
Mein Ameisenbeispiel oben ist natürlich nicht vollständig. Wir müssen noch die Ziele definieren, die zum Bereinigen, Kompilieren, Testen usw. verwendet werden. Diese werden in einer gemeinsamen Build-Datei definiert, die von allen Modulen im Projekt mit mehreren Modulen importiert wird. Was mich zu dem Punkt führt, wie all dieses Zeug explizit in Ant geschrieben werden muss, während es in Maven deklarativ ist.
Es ist wahr, es würde mir Zeit sparen, wenn ich diese Ant-Ziele nicht explizit schreiben müsste. Aber wie viel Zeit? Die übliche Build-Datei, die ich jetzt verwende, habe ich vor 5 Jahren mit nur geringfügigen Verbesserungen geschrieben. Nach meinem zweijährigen Experiment mit Maven zog ich die alte Ant-Build-Datei aus dem Schrank, wischte sie ab und legte sie wieder an die Arbeit. Für mich haben sich die Kosten, Ant explizit mitteilen zu müssen, über einen Zeitraum von 5 Jahren auf weniger als eine Woche summiert.
Komplexität
Der nächste große Unterschied, den ich erwähnen möchte, ist die Komplexität und der reale Effekt, den sie hat. Maven wurde mit der Absicht entwickelt, die Arbeitsbelastung der Entwickler zu verringern, die mit der Erstellung und Verwaltung von Erstellungsprozessen beauftragt sind. Dazu muss es komplex sein. Leider neigt diese Komplexität dazu, ihr beabsichtigtes Ziel zu negieren.
Im Vergleich zu Ant wird der Build-Typ eines Maven-Projekts mehr Zeit verbringen:
- Dokumentation lesen: Es gibt viel mehr Dokumentation zu Maven, weil Sie so viel mehr lernen müssen.
- Schulung der Teammitglieder: Sie finden es einfacher, jemanden zu fragen, der es weiß, als selbst nach Antworten zu suchen.
- Fehlerbehebung beim Build: Maven ist weniger zuverlässig als Ant, insbesondere die Nicht-Core-Plugins. Außerdem sind Maven-Builds nicht wiederholbar. Wenn Sie von einer SNAPSHOT-Version eines Plugins abhängig sind, was sehr wahrscheinlich ist, kann Ihr Build beschädigt werden, ohne dass Sie etwas geändert haben.
- Schreiben von Maven-Plugins: Plugins werden normalerweise für eine bestimmte Aufgabe geschrieben, z. B. zum Erstellen eines Webstart-Bundles, wodurch es schwieriger wird, sie für andere Aufgaben wiederzuverwenden oder zu kombinieren, um ein Ziel zu erreichen. Daher müssen Sie möglicherweise eine eigene schreiben, um Lücken im vorhandenen Plugin-Set zu umgehen.
Im Gegensatz:
- Die Dokumentation von Ant ist präzise, umfassend und an einem Ort.
- Ameise ist einfach. Ein neuer Entwickler, der versucht, Ant zu lernen, muss nur einige einfache Konzepte (Ziele, Aufgaben, Abhängigkeiten, Eigenschaften) verstehen, um den Rest dessen herauszufinden, was er wissen muss.
- Ameise ist zuverlässig. In den letzten Jahren gab es nicht sehr viele Veröffentlichungen von Ant, da dies bereits funktioniert.
- Ant-Builds sind wiederholbar, da sie im Allgemeinen ohne externe Abhängigkeiten wie Online-Repositorys, experimentelle Plugins von Drittanbietern usw. erstellt werden.
- Ameise ist umfassend. Da es sich um eine Toolbox handelt, können Sie die Tools kombinieren, um nahezu jede gewünschte Aufgabe auszuführen. Wenn Sie jemals Ihre eigene benutzerdefinierte Aufgabe schreiben müssen, ist dies sehr einfach.
Vertrautheit
Ein weiterer Unterschied ist der der Vertrautheit. Neue Entwickler benötigen immer Zeit, um sich auf den neuesten Stand zu bringen. Die Vertrautheit mit bestehenden Produkten hilft in dieser Hinsicht und Maven-Unterstützer behaupten zu Recht, dass dies ein Vorteil von Maven ist. Die Flexibilität von Ant bedeutet natürlich, dass Sie beliebige Konventionen erstellen können. Die Konvention, die ich verwende, besteht darin, meine Quelldateien in einem Verzeichnisnamen src / main / java abzulegen. Meine kompilierten Klassen werden in ein Verzeichnis mit dem Namen target / classes verschoben. Klingt vertraut, nicht wahr?
Ich mag die Verzeichnisstruktur von Maven. Ich denke es macht Sinn. Auch ihr Build-Lebenszyklus. Daher verwende ich in meinen Ant-Builds dieselben Konventionen. Nicht nur, weil es Sinn macht, sondern weil es jedem bekannt ist, der Maven schon einmal benutzt hat.