Ant contro Maven contro Gradle

Questo articolo fa parte di una serie: • Introduzione a Gradle

• Ant vs Maven vs Gradle (articolo attuale) • Scrittura di plugin Gradle personalizzati

• Creazione di un barattolo di grasso in Gradle

1. Introduzione

In questo articolo, esploreremo tre strumenti di automazione della build Java che hanno dominato l'ecosistema JVM: Ant, Maven e Gradle .

Presenteremo ciascuno di essi ed esploreremo come si sono evoluti gli strumenti di automazione della build Java.

2. Apache Ant

All'inizio, Make era l'unico strumento di automazione della build disponibile oltre alle soluzioni nostrane . Make esiste dal 1976 e come tale è stato utilizzato per la creazione di applicazioni Java nei primi anni di Java.

Tuttavia, molte convenzioni dei programmi C non si adattavano all'ecosistema Java, quindi col tempo Ant prese il sopravvento come alternativa migliore.

Apache Ant ("Another Neat Tool") è una libreria Java utilizzata per automatizzare i processi di compilazione per le applicazioni Java . Inoltre, Ant può essere utilizzato per creare applicazioni non Java. Inizialmente faceva parte del codice base di Apache Tomcat ed è stato rilasciato come progetto autonomo nel 2000.

Per molti aspetti, Ant è molto simile a Make, ed è abbastanza semplice da consentire a chiunque di iniziare a usarlo senza particolari prerequisiti. I file di build Ant sono scritti in XML e, per convenzione, sono chiamati build.xml .

Le diverse fasi di un processo di compilazione sono chiamate "obiettivi".

Ecco un esempio di un file build.xml per un semplice progetto Java con la classe principale HelloWorld :

Questo file di build definisce quattro obiettivi: clean , compile , jar ed run . Ad esempio, possiamo compilare il codice eseguendo:

ant compile

Questo attiverà prima il target clean che cancellerà la directory "classes". Dopodiché, la compilazione di destinazione ricrea la directory e compila la cartella src al suo interno.

Il vantaggio principale di Ant è la sua flessibilità. Ant non impone convenzioni di codifica o strutture di progetto. Di conseguenza, ciò significa che Ant richiede agli sviluppatori di scrivere tutti i comandi da soli, il che a volte porta a enormi file di build XML difficili da mantenere.

Poiché non ci sono convenzioni, conoscere Ant non significa che capiremo rapidamente qualsiasi file di build Ant. Probabilmente ci vorrà del tempo per abituarsi a un file Ant sconosciuto, il che è uno svantaggio rispetto agli altri strumenti più recenti.

All'inizio, Ant non aveva il supporto integrato per la gestione delle dipendenze. Tuttavia, poiché la gestione delle dipendenze è diventata un must negli ultimi anni, Apache Ivy è stato sviluppato come sottoprogetto del progetto Apache Ant. È integrato con Apache Ant e segue gli stessi principi di progettazione.

Tuttavia, le limitazioni iniziali di Ant dovute alla mancanza di supporto integrato per la gestione delle dipendenze e frustrazioni quando si lavora con file di compilazione XML non gestibili hanno portato alla creazione di Maven.

3. Apache Maven

Apache Maven è uno strumento di gestione delle dipendenze e di automazione della compilazione, utilizzato principalmente per le applicazioni Java. Maven continua a utilizzare file XML proprio come Ant ma in modo molto più gestibile. Il nome del gioco qui è convenzione sulla configurazione.

Mentre Ant offre flessibilità e richiede che tutto sia scritto da zero, Maven si basa su convenzioni e fornisce comandi (obiettivi) predefiniti.

In poche parole, Maven ci consente di concentrarci su ciò che la nostra build dovrebbe fare e ci fornisce il framework per farlo. Un altro aspetto positivo di Maven era che forniva supporto integrato per la gestione delle dipendenze.

Il file di configurazione di Maven, contenente le istruzioni per la compilazione e la gestione delle dipendenze, è per convenzione chiamato pom.xml . Inoltre, Maven prescrive anche una struttura di progetto rigorosa, mentre Ant fornisce flessibilità anche lì.

Ecco un esempio di un file pom.xml per lo stesso semplice progetto Java con la classe principale HelloWorld di prima:

 4.0.0 baeldung mavenExample 0.0.1-SNAPSHOT Maven example   junit junit 4.12 test   

Tuttavia, ora anche la struttura del progetto è stata standardizzata e conforme alle convenzioni Maven:

+---src | +---main | | +---java | | | \---com | | | \---baeldung | | | \---maven | | | HelloWorld.java | | | | | \---resources | \---test | +---java | \---resources

A differenza di Ant, non è necessario definire manualmente ciascuna delle fasi del processo di compilazione. Invece, possiamo semplicemente chiamare i comandi integrati di Maven.

Ad esempio, possiamo compilare il codice eseguendo:

mvn compile

At its core, as noted on official pages, Maven can be considered a plugin execution framework, since all work is done by plugins. Maven supports a wide range of available plugins, and each of them can be additionally configured.

One of the available plugins is Apache Maven Dependency Plugin which has a copy-dependencies goal that will copy our dependencies to a specified directory.

To show this plugin in action, let's include this plugin in our pom.xml file and configure an output directory for our dependencies:

   org.apache.maven.plugins maven-dependency-plugin   copy-dependencies package  copy-dependencies   target/dependencies       

This plugin will be executed in a package phase, so if we run:

mvn package

We'll execute this plugin and copy dependencies to the target/dependencies folder.

There is also an existing article on how to create an executable JAR using different Maven plugins. Additionally, for a detailed Maven overview, have a look at this core guide on Maven, where some Maven's key features are explored.

Maven became very popular since build files were now standardized and it took significantly less time to maintain build files, comparing to Ant. However, though more standardized than Ant files, Maven configuration files still tend to get big and cumbersome.

Maven's strict conventions come with the price of being a lot less flexible than Ant. Goal customization is very hard, so writing custom build scripts is a lot harder to do, compared with Ant.

Although Maven has made some serious improvements regarding making application's build processes easier and more standardized, it still comes with a price due to being a lot less flexible than Ant. This lead to the creation of Gradle which combines the best of both worlds – Ant's flexibility and Maven's features.

4. Gradle

Gradle is a dependency management and a build automation tool that was built upon the concepts of Ant and Maven.

One of the first things we can note about Gradle is that it's not using XML files, unlike Ant or Maven.

Over time, developers became more and more interested in having and working with a domain-specific language – which, simply put, would allow them to solve problems in a specific domain using a language tailored for that particular domain.

This was adopted by Gradle, which is using a DSL based either on Groovy or Kotlin. This led to smaller configuration files with less clutter since the language was specifically designed to solve specific domain problems. Gradle's configuration file is by convention called build.gradle in Groovy, or build.gradle.kts in Kotlin.

Notice that Kotlin offers better IDE support than Groovy for auto-completion and error detection.

Here is an example of a build.gradle file for the same simple Java project with the HelloWorld main class from before:

apply plugin: 'java' repositories { mavenCentral() } jar { baseName = 'gradleExample' version = '0.0.1-SNAPSHOT' } dependencies { testImplementation 'junit:junit:4.12' }

We can compile the code by running:

gradle classes

At its core, Gradle intentionally provides very little functionality. Plugins add all useful features. In our example, we were using java plugin which allows us to compile Java code and other valuable features.

Gradle gave its build steps name “tasks”, as opposed to Ant's “targets” or Maven's “phases”. With Maven, we used Apache Maven Dependency Plugin, and it's a specific goal to copy dependencies to a specified directory. With Gradle, we can do the same by using tasks:

task copyDependencies(type: Copy) { from configurations.compile into 'dependencies' }

We can run this task by executing:

gradle copyDependencies

5. Conclusion

In this article, we presented Ant, Maven, and Gradle – three Java build automation tools.

Not surprisingly, Maven holds the majority of the build tool market today.

Gradle, tuttavia, ha visto una buona adozione in basi di codice più complesse, per i seguenti motivi:

  • Molti progetti open-source come Spring lo stanno usando ora
  • È più veloce di Maven per la maggior parte degli scenari, grazie alle sue build incrementali
  • Offre analisi avanzate e servizi di debug

Tuttavia quel Gradle sembra avere una curva di apprendimento più ripida, soprattutto se non hai familiarità con Groovy o Kotlin.

Successivo » Scrittura di plug-in Gradle personalizzati « Precedente Introduzione a Gradle