wake-up-neo.net

Unterschiede zwischen Ant und Maven

Kann mir jemand die Unterschiede zwischen Ant und Maven erklären? Ich habe auch noch nie benutzt. Ich verstehe, dass sie verwendet werden, um das Erstellen von Java) - Projekten zu automatisieren, aber ich weiß nicht, wo ich anfangen soll.

177
rtacconi

In Maven: The Definitive Guide schrieb ich über die Unterschiede zwischen Maven und Ant in der Einleitung, dass der Abschnittstitel "Die Unterschiede zwischen Ant und Maven" lautet. Hier ist eine Antwort, die eine Kombination der Informationen in dieser Einleitung mit einigen zusätzlichen Anmerkungen ist.

Ein einfacher Vergleich

Ich zeige Ihnen dies nur, um die Idee zu veranschaulichen, dass Maven auf der einfachsten Ebene integrierte Konventionen hat. Hier ist eine einfache Ant-Build-Datei:

<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>

In diesem einfachen Ant-Beispiel können Sie sehen, wie Sie Ant genau mitteilen müssen, was zu tun ist. Es gibt ein Kompilierungsziel, das die Javac-Task enthält, die die Quelle im Verzeichnis src/main/Java in das Verzeichnis target/classes kompiliert. Sie müssen Ant genau mitteilen, wo sich Ihre Quelle befindet, wo der resultierende Bytecode gespeichert werden soll und wie dies alles in eine JAR-Datei gepackt werden soll. Während es in letzter Zeit einige Entwicklungen gibt, die dazu beitragen, Ant weniger prozedural zu machen, besteht die Erfahrung eines Entwicklers mit Ant darin, eine in XML geschriebene prozedurale Sprache zu codieren.

Vergleichen Sie das vorherige Ant-Beispiel mit einem Maven-Beispiel. Um in Maven eine JAR-Datei aus einer Java -Quelle zu erstellen, müssen Sie lediglich eine einfache pom.xml erstellen, Ihren Quellcode in $ {basedir}/src/main/Java ablegen und dann ausführen mvn install von der Kommandozeile aus. Das Beispiel Maven pom.xml, das die gleichen Ergebnisse erzielt.

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

Das ist alles was Sie in Ihrer pom.xml brauchen. Wenn Sie mvn install über die Befehlszeile ausführen, werden Ressourcen verarbeitet, der Quellcode kompiliert, Komponententests ausgeführt, eine JAR erstellt und die JAR in einem lokalen Repository zur Wiederverwendung in anderen Projekten installiert. Ohne Änderungen können Sie mvn site ausführen und dann eine index.html-Datei in target/site finden, die Links zu JavaDoc und einige Berichte zu Ihrem Quellcode enthält.

Zugegeben, dies ist das einfachste mögliche Beispielprojekt. Ein Projekt, das nur Quellcode enthält und eine JAR erzeugt. Ein Projekt, das den Konventionen von Maven folgt und keine Abhängigkeiten oder Anpassungen erfordert. Wenn wir mit dem Anpassen des Verhaltens beginnen wollten, wird unsere pom.xml immer größer, und in den größten Projekten sehen Sie Sammlungen sehr komplexer Maven-POMs, die eine Menge Plugin-Anpassungen und Abhängigkeitsdeklarationen enthalten. Aber selbst wenn die POM-Dateien Ihres Projekts umfangreicher werden, enthalten sie eine völlig andere Art von Informationen als die Build-Datei eines Projekts mit ähnlicher Größe, das Ant verwendet. Maven-POMs enthalten Deklarationen: "Dies ist ein JAR-Projekt" und "Der Quellcode befindet sich in src/main/Java". Ant-Build-Dateien enthalten explizite Anweisungen: "Dies ist ein Projekt", "Die Quelle ist in src/main/Java", "Führe javac für dieses Verzeichnis aus", "Gib die Ergebnisse in target/classses Msgstr "" "Erstellen Sie eine JAR aus dem ....", usw. Wo Ant explizit über den Prozess sein musste, war etwas "Eingebautes" für Maven, das nur wusste, wo sich der Quellcode befand und wie er verarbeitet werden sollte .

Vergleich auf hoher Ebene

Die Unterschiede zwischen Ant und Maven in diesem Beispiel? Ameise...

  • hat Ant keine formalen Konventionen wie eine allgemeine Projektverzeichnisstruktur, müssen Sie Ant genau mitteilen, wo sich die Quelle befindet und wo die Ausgabe erfolgen soll. Im Laufe der Zeit haben sich informelle Konventionen herausgebildet, die jedoch nicht im Produkt kodifiziert wurden.
  • wenn es sich um ein verfahren handelt, müssen Sie Ant genau mitteilen, was und wann zu tun ist. Sie mussten es kompilieren, dann kopieren und dann komprimieren.
  • hat keinen Lebenszyklus, man musste Ziele und Zielabhängigkeiten definieren. Sie mussten jedem Ziel manuell eine Abfolge von Aufgaben zuordnen.

Wo Maven ...

  • konventionen hat, wusste es bereits, wo Ihr Quellcode war, weil Sie die Konvention befolgt haben. Es hat den Bytecode in target/classes abgelegt und eine JAR-Datei in target erstellt.
  • ist deklarativ. Sie mussten lediglich eine pom.xml-Datei erstellen und Ihre Quelle in das Standardverzeichnis stellen. Maven kümmerte sich um den Rest.
  • hat einen Lebenszyklus, den Sie beim Ausführen von mvn install aufgerufen haben. Dieser Befehl forderte Maven auf, eine Reihe von Sequenzschritten auszuführen, bis der Lebenszyklus erreicht ist. Als Nebeneffekt dieser Reise durch den Lebenszyklus führte Maven eine Reihe von Standard-Plug-in-Zielen aus, bei denen beispielsweise eine JAR kompiliert und erstellt wurde.

Was ist mit Efeu?

Richtig, jemand wie Steve Loughran wird diesen Vergleich lesen und Foul nennen. Er wird darüber sprechen, wie die Antwort Ivy völlig ignoriert und die Tatsache, dass Ant Build-Logik in den neueren Versionen von Ant wiederverwenden kann. Das ist wahr. Wenn Sie eine Menge kluger Leute haben, die Ant + antlibs + Ivy verwenden, erhalten Sie einen gut gestalteten Build, der funktioniert. Obwohl ich sehr davon überzeugt bin, dass Maven Sinn macht, würde ich Ant + Ivy gerne mit einem Projektteam verwenden, das einen sehr scharfen Build-Ingenieur hatte. Abgesehen davon denke ich, dass Sie am Ende eine Reihe von nützlichen Plugins wie das Jetty-Plugin verpassen werden und am Ende eine ganze Reihe von Arbeiten erledigen werden, die Sie im Laufe der Zeit nicht erledigen mussten.

Wichtiger als Maven vs. Ant

  1. Verwenden Sie einen Repository-Manager, um Software-Artefakte zu verfolgen. Ich würde vorschlagen Nexus herunterladen . Sie können Nexus als Proxy für Remote-Repositorys verwenden und Ihrem Team einen Platz zum Bereitstellen interner Artefakte bereitstellen.
  2. Sie haben eine entsprechende Modularisierung der Softwarekomponenten. Eine große monolithische Komponente skaliert selten mit der Zeit. Während sich Ihr Projekt entwickelt, möchten Sie das Konzept von Modulen und Untermodulen haben. Maven bietet sich für diesen Ansatz sehr gut an.
  3. Sie übernehmen einige Konventionen für Ihren Build. Selbst wenn Sie Ant verwenden, sollten Sie sich bemühen, eine Konvention einzuführen, die mit anderen Projekten konsistent ist. Wenn ein Projekt Maven verwendet, bedeutet dies, dass jeder, der mit Maven vertraut ist, den Build abrufen und damit beginnen kann, ohne sich mit der Konfiguration herumschlagen zu müssen, um herauszufinden, wie das Ding kompiliert werden kann.
216
Tim O'Brien

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 ist Maven 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 meiner Meinung nach einen sehr guten, ehrlichen Vergleich der beiden Produkte liefert. Er verglich eine einfache Maven pom.xml mit einer einfachen Ant-Build-Datei und erwähnte, wie Maven-Projekte komplexer werden können. Ich denke, dass es sich lohnt, sich einen Vergleich einiger Dateien anzusehen, die Sie in einem einfachen realen Projekt mit größerer Wahrscheinlichkeit 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 anhand seines Beispiels gezeigt, dass Maven über integrierte Konventionen verfügt. Dies bedeutet jedoch nicht unbedingt, dass Sie weniger XML schreiben. Ich habe das Gegenteil für wahr befunden. 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 gezeigt, die zum Konfigurieren von Plugins erforderlich waren. Diese pom.xml ist für ein einfaches Projekt. Das XML-Format wächst 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

Das obige Ant-Beispiel 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 Multi-Modul-Projekt 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 gemeinsame Build-Datei, die ich jetzt verwende, ist eine, die ich vor 5 Jahren mit nur geringfügigen Verbesserungen seitdem geschrieben habe. Nach meinem zweijährigen Experiment mit Maven zog ich die alte Ant Build-Datei aus dem Schrank, wischte sie ab und stellte sie wieder an die Arbeit. Für mich haben sich die Kosten für die ausdrückliche Anweisung von Ant, was zu tun ist, über einen Zeitraum von 5 Jahren auf weniger als eine Woche belaufen.

Komplexität

Der nächste große Unterschied, den ich erwähnen möchte, ist die Komplexität und der reale Effekt. Maven wurde mit dem Ziel entwickelt, die Arbeitslast 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 verbringt der Entwickler eines Maven-Projekts mehr Zeit:

  • Dokumentation lesen: Es gibt viel mehr Dokumentation über Maven, weil Sie so viel mehr lernen müssen.
  • Schulung von Teammitgliedern: 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 können Maven-Builds nicht wiederholt werden. Wenn Sie sich sehr wahrscheinlich auf eine SNAPSHOT-Version eines Plugins verlassen, kann Ihr Build abbrechen, ohne dass Sie etwas geändert haben.
  • Schreiben von Maven-Plugins: Plugins werden normalerweise für eine bestimmte Aufgabe geschrieben, z. Erstellen Sie ein Webstart-Bundle, das es schwieriger macht, sie für andere Aufgaben wiederzuverwenden oder sie zu kombinieren, um ein Ziel zu erreichen. Daher müssen Sie möglicherweise eine eigene schreiben, um die Lücken im vorhandenen Plug-in-Set zu schließen.

Im Gegensatz:

  • Die Dokumentation von Ant ist übersichtlich, umfassend und alles an einem Ort.
  • Ameise ist einfach. Ein neuer Entwickler, der versucht, Ant zu erlernen, muss nur ein paar einfache Konzepte (Ziele, Aufgaben, Abhängigkeiten, Eigenschaften) verstehen, um den Rest dessen herauszufinden, was er wissen muss.
  • Ameise ist zuverlässig. Es gab in den letzten Jahren nicht sehr viele Releases von Ant, da es bereits funktioniert.
  • Ant-Builds sind wiederholbar, da sie in der Regel ohne externe Abhängigkeiten erstellt werden, z. B. Online-Repositorys, experimentelle Plugins von Drittanbietern usw.
  • 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 eine eigene benutzerdefinierte Aufgabe schreiben müssen, ist dies sehr einfach.

Vertrautheit

Ein weiterer Unterschied ist die 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 die Maven-Unterstützer behaupten zu Recht, dass dies ein Vorteil von Maven ist. Natürlich bedeutet die Flexibilität von Ant, dass Sie beliebige Konventionen erstellen können. Die Konvention, die ich verwende, besteht darin, meine Quelldateien in einem Verzeichnis mit dem Namen src/main/Java abzulegen. Meine kompilierten Klassen gehen in ein Verzeichnis namens target/classes. Klingt vertraut, nicht wahr?.

Mir gefällt die von Maven verwendete Verzeichnisstruktur. Ich finde es sinnvoll. 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.

112

Ant ist hauptsächlich ein Build-Tool.

Maven ist ein Projekt- und Abhängigkeitsmanagement-Tool (das natürlich auch Ihr Projekt erstellt).

Ant + Ivy ist eine ziemlich gute Kombination, wenn Sie Maven aus dem Weg gehen möchten.

20
cherouvim

Maven oder Ant? ist eine sehr ähnliche Frage wie diese, die Ihnen bei der Beantwortung Ihrer Fragen helfen sollte.

Was ist Maven? auf der offiziellen Seite.

edit: Für ein neues/neues Projekt würde ich empfehlen, Maven zu verwenden: "Konvention über Konfiguration" spart Ihnen ein gutes Stück Zeit beim Schreiben und Einrichten von Erstellungs- und Bereitstellungsskripten. Wenn Sie ant verwenden, nimmt die Länge und Komplexität des Build-Skripts im Laufe der Zeit zu. Bei bestehenden Projekten kann es schwierig sein, deren Konfiguration/Layout in das Maven-System zu übernehmen.

17
matt b

Um nur einige weitere Unterschiede aufzulisten:

  • Ant hat keine formalen Konventionen. Sie müssen Ant genau mitteilen, wo die Quelle zu finden ist, wo die Ausgänge abzulegen sind usw.
  • Ant ist prozedural. Sie müssen Ant genau sagen, was zu tun ist; Sagen Sie ihm, er soll kompilieren, kopieren, dann komprimieren usw.
  • Ant hat keinen Lebenszyklus.
  • Maven verwendet Konventionen. Es weiß, wo sich Ihr Quellcode automatisch befindet, solange Sie diese Konventionen einhalten. Sie müssen Maven nicht sagen, wo es ist.
  • Maven ist deklarativ; Sie müssen lediglich eine pom.xml-Datei erstellen und Ihre Quelle in das Standardverzeichnis stellen. Maven wird sich um den Rest kümmern.
  • Maven hat einen Lebenszyklus. Sie rufen einfach mvn install auf und eine Reihe von Sequenzschritten wird ausgeführt.
  • Maven verfügt über Informationen zu allgemeinen Projektaufgaben. Führen Sie zum Ausführen von Tests einfach mvn test aus, solange sich die Dateien am Standardspeicherort befinden. In Ant müssten Sie zuerst die JUnit-JAR-Datei is erstellen, dann einen Klassenpfad, der die JUnit-JAR enthält, und dann Ant mitteilen, wo er nach Testquellcode suchen soll, ein Ziel schreiben, das die Testquelle kompiliert, und anschließend die Komponententests ausführen mit JUnit.

Update:

Dies kam von Maven: The Definitive Guide . Entschuldigung, ich habe völlig vergessen, es zu zitieren.

16
Ascalonian

Maven fungiert sowohl als Abhängigkeitsmanagement-Tool - es kann zum Abrufen von Jars aus einem zentralen Repository oder einem von Ihnen eingerichteten Repository verwendet werden - als auch als deklaratives Build-Tool. Der Unterschied zwischen einem "deklarativen" Build-Tool und einem traditionelleren wie ant oder make besteht darin, dass Sie konfigurieren, was erledigt werden muss und nicht, wie es erledigt wird. Zum Beispiel können Sie in einem Maven-Skript sagen, dass ein Projekt als WAR-Datei gepackt werden soll, und Maven weiß, wie man damit umgeht.

Maven stützt sich auf Konventionen bezüglich der Anordnung von Projektverzeichnissen, um die "Deklarativität" zu erreichen. Beispielsweise gibt es eine Konvention, wo Sie Ihren Hauptcode, Ihre web.xml, Ihre Komponententests usw. ablegen, aber auch die Möglichkeit, sie bei Bedarf zu ändern.

Sie sollten auch bedenken, dass es ein Plugin für die Ausführung von Ant-Befehlen innerhalb von Maven gibt:

http://maven.Apache.org/plugins/maven-ant-plugin/

Die Archetypen von Maven ermöglichen außerdem einen schnellen Einstieg in ein Projekt. Zum Beispiel gibt es einen Wicket-Archetyp, der einen von Ihnen ausgeführten Maven-Befehl bereitstellt, um ein ganzes, einsatzbereites Hallo-Welt-Projekt zu erhalten.

https://wicket.Apache.org/start/quickstart.html

14
James Kingsbery

Ich kann eine Person nehmen, die Ameise nie gesehen hat - sein build.xmls sind einigermaßen gut geschrieben - und sie können verstehen, was los ist. Ich kann dieselbe Person nehmen und ihnen einen Maven POM zeigen, und sie werden keine Ahnung haben, was los ist.

In einer riesigen technischen Organisation wird darüber geschrieben, dass Ant-Dateien groß und unhandlich werden. Ich habe diese Typen geschrieben nd saubere Ant-Skripte. Es ist wirklich wichtig, im Voraus zu verstehen, was Sie in Zukunft tun müssen, und eine Reihe von Vorlagen zu entwerfen, die auf Änderungen reagieren und über einen Zeitraum von mehr als 3 Jahren skaliert werden können.

Wenn Sie kein einfaches Projekt haben, ist das Erlernen der Maven-Konventionen und der Maven-Methode zur Erledigung von Aufgaben ein ziemlicher Arbeitsaufwand.

Letztendlich können Sie den Projektstart mit Ant oder Maven nicht als einen Faktor betrachten: Es sind wirklich die Gesamtbetriebskosten. Was die Organisation braucht, um ihr Build-System über einige Jahre zu warten und zu erweitern, ist einer der wichtigsten Faktoren, die berücksichtigt werden müssen.

Die wichtigsten Aspekte eines Build-Systems sind das Abhängigkeitsmanagement und die Flexibilität beim Ausdrücken des Build-Rezepts. Es muss etwas intuitiv sein, wenn es gut gemacht ist.

10
kramer

Ich würde sagen, es hängt von der Größe Ihres Projekts ab ... Persönlich würde ich Maven für einfache Projekte verwenden, die eine einfache Kompilierung, Verpackung und Bereitstellung erfordern. Sobald Sie kompliziertere Dinge tun müssen (viele Abhängigkeiten, Zuordnungsdateien erstellen ...), würde ich zu Ant wechseln ...

6
karlipoppins

Maven beherbergt auch ein großes Repository mit häufig verwendeten Open Source-Projekten. Während des Builds kann Maven diese Abhängigkeiten für Sie herunterladen (sowie Ihre Abhängigkeiten-Abhängigkeiten :)), um diesen Teil des Builds eines Projekts ein wenig übersichtlicher zu gestalten.

4
markt