Maven è un framework, Ant è una cassetta degli attrezzi
Maven è un'auto stradale pre-costruita, mentre Ant è un insieme di parti di automobili. Con Ant devi costruire la tua auto, ma almeno se devi fare qualsiasi guida fuoristrada puoi costruire il giusto tipo di auto.
Per dirla in altro modo, Maven è un framework mentre Ant è una cassetta degli attrezzi. Se ti accontenti di lavorare entro i limiti del framework, Maven farà bene. Il problema per me era che continuavo a sbattere contro i limiti della struttura e non mi lasciava uscire.
Verbosità XML
tobrien è un ragazzo che sa molto di Maven e penso che abbia fornito un confronto molto buono e onesto tra i due prodotti. Ha confrontato un semplice pom.xml di Maven con un semplice file di build Ant e ha fatto menzione di come i progetti Maven possano diventare più complessi. Penso che valga la pena dare un'occhiata al confronto di un paio di file che è più probabile che tu veda in un semplice progetto del mondo reale. I file seguenti rappresentano un singolo modulo in una build multi-modulo.
Innanzitutto, il file 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>
E il file Ant equivalente:
<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 ha usato il suo esempio per dimostrare che Maven ha convenzioni integrate, ma ciò non significa necessariamente che tu finisca per scrivere meno XML. Ho trovato il contrario per essere vero. Il pom.xml è 3 volte più lungo del build.xml e cioè senza allontanarsi dalle convenzioni. In effetti, il mio esempio di Maven è mostrato senza altre 54 righe necessarie per configurare i plugin. Quel pom.xml è per un semplice progetto. L'XML inizia davvero a crescere in modo significativo quando inizi ad aggiungere requisiti extra, che non è fuori dall'ordinario per molti progetti.
Ma devi dire ad Ant cosa fare
Il mio esempio di formica sopra non è completo ovviamente. Dobbiamo ancora definire gli obiettivi utilizzati per pulire, compilare, testare ecc. Questi sono definiti in un file di build comune che viene importato da tutti i moduli nel progetto multi-modulo. Il che mi porta al punto su come tutta questa roba debba essere esplicitamente scritta in Ant mentre è dichiarativa in Maven.
È vero, mi farebbe risparmiare tempo se non dovessi scrivere esplicitamente questi target di formiche. Ma quanto tempo? Il file di build comune che uso ora è quello che ho scritto 5 anni fa con solo lievi perfezionamenti da allora. Dopo il mio esperimento di 2 anni con Maven, ho estratto il vecchio file di build Ant dall'armadio, l'ho rispolverato e rimesso a posto. Per me, il costo di dover dire esplicitamente ad Ant cosa fare è aumentato a meno di una settimana per un periodo di 5 anni.
Complessità
La prossima grande differenza che vorrei menzionare è quella della complessità e dell'effetto nel mondo reale che ha. Maven è stato creato con l'intento di ridurre il carico di lavoro degli sviluppatori incaricati di creare e gestire i processi di compilazione. Per fare ciò deve essere complesso. Sfortunatamente questa complessità tende a negare l'obiettivo prefissato.
Rispetto a Ant, il ragazzo del build su un progetto Maven passerà più tempo:
- Leggere la documentazione: c'è molta più documentazione su Maven, perché c'è molto di più che devi imparare.
- Educare i membri del team: trovano più facile chiedere a qualcuno che conosce piuttosto che cercare di trovare risposte da soli.
- Risoluzione dei problemi relativi alla build: Maven è meno affidabile di Ant, in particolare i plug-in non core. Inoltre, le build di Maven non sono ripetibili. Se dipendi da una versione SNAPSHOT di un plugin, il che è molto probabile, la tua build può interrompersi senza che tu abbia cambiato nulla.
- Scrivere plug-in Maven: i plug-in sono in genere scritti con in mente un'attività specifica, ad esempio creare un pacchetto webstart, che rende più difficile riutilizzarli per altre attività o combinarli per raggiungere un obiettivo. Quindi potresti dover scrivere uno dei tuoi per colmare le lacune nel set di plugin esistente.
In contrasto:
- La documentazione della formica è concisa, completa e in un unico posto.
- La formica è semplice. Un nuovo sviluppatore che cerca di imparare la formica deve solo comprendere alcuni concetti semplici (obiettivi, attività, dipendenze, proprietà) per essere in grado di capire il resto di ciò che devono sapere.
- La formica è affidabile. Non ci sono state molte versioni di Ant negli ultimi anni perché funziona già.
- Le build di formiche sono ripetibili perché generalmente vengono create senza dipendenze esterne, come repository online, plug-in di terze parti sperimentali ecc.
- La formica è completa. Poiché si tratta di una cassetta degli attrezzi, è possibile combinare gli strumenti per eseguire quasi tutte le attività desiderate. Se hai mai bisogno di scrivere il tuo compito personalizzato, è molto semplice da fare.
Familiarità
Un'altra differenza è quella della familiarità. I nuovi sviluppatori richiedono sempre tempo per essere aggiornati. La familiarità con i prodotti esistenti aiuta in tal senso e i sostenitori di Maven affermano giustamente che questo è un vantaggio di Maven. Naturalmente, la flessibilità di Ant significa che puoi creare qualunque convenzione ti piaccia. Quindi la convenzione che uso è quella di mettere i miei file sorgente in un nome di directory src / main / java. Le mie classi compilate vanno in una directory denominata target / classi. Sembra familiare no?
Mi piace la struttura di directory utilizzata da Maven. Penso che abbia senso. Anche il loro ciclo di vita della build. Quindi uso le stesse convenzioni nei miei build Ant. Non solo perché ha senso, ma perché sarà familiare a chiunque abbia già usato Maven.