Hormiga vs Maven vs Gradle

Programación
Este artículo es parte de una serie: • Introducción a Gradle

• Ant vs Maven vs Gradle (artículo actual) • Escribiendo complementos personalizados de Gradle

• Creando un Fat Jar en Gradle

1. Introducción

En este artículo, exploraremos tres herramientas de automatización de compilación de Java que dominaron el ecosistema de JVM: Ant, Maven y Gradle .

Presentaremos cada uno de ellos y exploraremos cómo evolucionaron las herramientas de automatización de compilación de Java.

2. Apache Ant

Al principio, Make era la única herramienta de automatización de construcción disponible más allá de las soluciones de cosecha propia . Make existe desde 1976 y, como tal, se utilizó para crear aplicaciones Java en los primeros años de Java.

Sin embargo, muchas convenciones de los programas C no encajaban en el ecosistema de Java, por lo que con el tiempo Ant asumió el control como una mejor alternativa.

Apache Ant ("Otra herramienta ordenada") es una biblioteca de Java que se utiliza para automatizar los procesos de compilación de aplicaciones Java . Además, Ant se puede utilizar para crear aplicaciones que no sean Java. Inicialmente formaba parte del código base de Apache Tomcat y se lanzó como proyecto independiente en 2000.

En muchos aspectos, Ant es muy similar a Make, y es lo suficientemente simple como para que cualquiera pueda comenzar a usarlo sin ningún requisito previo en particular. Los archivos de compilación de Ant están escritos en XML y, por convención, se denominan build.xml .

Las diferentes fases de un proceso de construcción se denominan "objetivos".

Aquí hay un ejemplo de un archivo build.xml para un proyecto Java simple con la clase principal HelloWorld :

Este archivo de compilación define cuatro objetivos: limpiar , compilar , jar y ejecutar . Por ejemplo, podemos compilar el código ejecutando:

ant compile

Esto activará primero la limpieza de destino, que eliminará el directorio de "clases". Después de eso, la compilación de destino volverá a crear el directorio y compilará la carpeta src en él.

El principal beneficio de Ant es su flexibilidad. Ant no impone convenciones de codificación ni estructuras de proyecto. En consecuencia, esto significa que Ant requiere que los desarrolladores escriban todos los comandos por sí mismos, lo que a veces conduce a enormes archivos de compilación XML que son difíciles de mantener.

Dado que no existen convenciones, el simple hecho de conocer Ant no significa que entenderemos rápidamente cualquier archivo de compilación de Ant. Es probable que te lleve un tiempo acostumbrarte a un archivo Ant desconocido, lo cual es una desventaja en comparación con las otras herramientas más nuevas.

Al principio, Ant no tenía soporte integrado para la gestión de dependencias. Sin embargo, como la gestión de dependencias se convirtió en una necesidad en los últimos años, Apache Ivy se desarrolló como un subproyecto del proyecto Apache Ant. Está integrado con Apache Ant y sigue los mismos principios de diseño.

Sin embargo, las limitaciones iniciales de Ant debido a no tener soporte integrado para la administración de dependencias y las frustraciones al trabajar con archivos de compilación XML no administrables llevaron a la creación de Maven.

3. Apache Maven

Apache Maven es una herramienta de automatización de compilación y gestión de dependencias, que se utiliza principalmente para aplicaciones Java. Maven continúa usando archivos XML como Ant pero de una manera mucho más manejable. El nombre del juego aquí es convención sobre configuración.

Mientras que Ant brinda flexibilidad y requiere que todo se escriba desde cero, Maven se basa en convenciones y proporciona comandos predefinidos (objetivos).

En pocas palabras, Maven nos permite centrarnos en lo que debería hacer nuestra construcción y nos brinda el marco para hacerlo. Otro aspecto positivo de Maven fue que proporcionó soporte integrado para la gestión de dependencias.

El archivo de configuración de Maven, que contiene instrucciones de gestión de dependencia y compilación, se llama por convención pom.xml . Además, Maven también prescribe una estructura de proyecto estricta, mientras que Ant también proporciona flexibilidad allí.

Aquí hay un ejemplo de un archivo pom.xml para el mismo proyecto Java simple con la clase principal HelloWorld de antes:

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

Sin embargo, ahora la estructura del proyecto también se ha estandarizado y se ajusta a las convenciones de Maven:

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

A diferencia de Ant, no es necesario definir manualmente cada una de las fases del proceso de compilación. En cambio, podemos simplemente llamar a los comandos integrados de Maven.

Por ejemplo, podemos compilar el código ejecutando:

mvn compile

En esencia, como se indica en las páginas oficiales, Maven puede considerarse un marco de ejecución de complementos, ya que todo el trabajo se realiza mediante complementos. Maven admite una amplia gama de complementos disponibles, y cada uno de ellos se puede configurar adicionalmente.

Uno de los complementos disponibles es Apache Maven Dependency Plugin, que tiene un objetivo de copia de dependencias que copiará nuestras dependencias en un directorio específico.

Para mostrar este complemento en acción, incluyamos este complemento en nuestro archivo pom.xml y configuremos un directorio de salida para nuestras dependencias:

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

Este complemento se ejecutará en una fase de paquete , así que si ejecutamos:

mvn package

Ejecutaremos este complemento y copiaremos las dependencias en la carpeta de destino / dependencias.

También hay un artículo existente sobre cómo crear un JAR ejecutable utilizando diferentes complementos de Maven. Además, para obtener una descripción general detallada de Maven, eche un vistazo a esta guía principal sobre Maven, donde se exploran algunas de las características clave de Maven.

Maven se hizo muy popular ya que los archivos de compilación ahora estaban estandarizados y llevó mucho menos tiempo mantener los archivos de compilación, en comparación con Ant. Sin embargo, aunque están más estandarizados que los archivos Ant, los archivos de configuración de Maven aún tienden a ser grandes y engorrosos.

Las estrictas convenciones de Maven tienen el precio de ser mucho menos flexible que Ant. La personalización de objetivos es muy difícil, por lo que escribir scripts de compilación personalizados es mucho más difícil de hacer, en comparación con Ant.

Aunque Maven ha realizado algunas mejoras serias con respecto a hacer que los procesos de construcción de aplicaciones sean más fáciles y estandarizados, todavía tiene un precio debido a que es mucho menos flexible que Ant. Esto llevó a la creación de Gradle, que combina lo mejor de ambos mundos: la flexibilidad de Ant y las características de Maven.

4. Gradle

Gradle es una herramienta de automatización de compilación y gestión de dependencias que se basó en los conceptos de Ant y Maven.

Una de las primeras cosas que podemos notar sobre Gradle es que no usa archivos XML, a diferencia de Ant o Maven.

Con el tiempo, los desarrolladores se interesaron cada vez más en tener y trabajar con un lenguaje específico de dominio, que, en pocas palabras, les permitiría resolver problemas en un dominio específico utilizando un lenguaje adaptado a ese dominio en particular.

Esto fue adoptado por Gradle, que utiliza un DSL basado en Groovy o Kotlin. Esto llevó a archivos de configuración más pequeños con menos desorden, ya que el lenguaje fue diseñado específicamente para resolver problemas de dominio específicos. El archivo de configuración de Gradle se llama por convención build.gradle en Groovy, o build.gradle.kts en Kotlin.

Tenga en cuenta que Kotlin ofrece una mejor compatibilidad con IDE que Groovy para el autocompletado y la detección de errores.

Aquí hay un ejemplo de un archivo build.gradle para el mismo proyecto Java simple con la clase principal HelloWorld de antes:

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

Podemos compilar el código ejecutando:

gradle classes

En esencia, Gradle proporciona intencionalmente muy poca funcionalidad. Los complementos agregan todas las funciones útiles. En nuestro ejemplo, estábamos usando un complemento de Java que nos permite compilar código Java y otras características valiosas.

Gradle dio a sus pasos de construcción el nombre de "tareas", en contraposición a los "objetivos" de Ant o las "fases" de Maven. Con Maven, usamos Apache Maven Dependency Plugin, y es un objetivo específico copiar las dependencias a un directorio específico. Con Gradle, podemos hacer lo mismo usando tareas:

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

Podemos ejecutar esta tarea ejecutando:

gradle copyDependencies

5. Conclusión

En este artículo, presentamos Ant, Maven y Gradle, tres herramientas de automatización de compilación de Java.

No es sorprendente que Maven posea la mayor parte del mercado de herramientas de construcción en la actualidad.

Gradle, sin embargo, ha tenido una buena adopción en bases de código más complejas, por las siguientes razones:

  • Muchos proyectos de código abierto como Spring lo están usando ahora
  • Es más rápido que Maven para la mayoría de los escenarios, gracias a sus compilaciones incrementales.
  • Ofrece servicios avanzados de análisis y depuración.

Sin embargo, Gradle parece tener una curva de aprendizaje más pronunciada, especialmente si no está familiarizado con Groovy o Kotlin.

Siguiente » Escribir complementos personalizados de Gradle « Introducción anterior a Gradle