Gradle, reunión del Madrid GUG, abril de 2012

En la reunión de este mes del GUG tuvimos la suerte de que Mario García (@marioggar) nos hiciera una pequeña presentación de Gradle y lo “enfrentara” en un combate contra Maven.

Empezamos con un breve repaso histórico a las herramientas de “build”.

Partimos en el año 2000 cuando fue lanzado Apache Ant, una herramienta donde prima la configuración sobre la convención, basado en xml y en general muy verbosa aunque también muy flexible pero sin gestión de dependencias.

A continuación llegamos a Maven, justo al contrario, un modelo de convención sobre configuración, también basado en xml aunque menos verboso y con el avance en la gestión de dependencias, aunque es menos flexible.

Y aterrizamos por fin en Gradle. Una herramienta de construcción de software que combina la flexibilidad de Ant con las convenciones de Maven. En ella podemos utilizar Groovy a través de un DSL y crear tareas sin descuidar la convención. El uso de Groovy nos permite reducir el número de líneas de código y además, al ser código, puedes hacer cosas como trazar, testear, etc.

Y una vez presentados a los contrincantes, pasamos al combate Maven vs Gradle:

Round 1: Xml vs código

Mientras Maven se basa en xml y siempre tienes que escribir una serie de etiquetas para realizar ciertas tareas, Gradle te permite hacer lo mismo pero con código.

Round 2: Convención sobre configuración.

Aunque ambos parten de convenciones, Gradle permite extender la convención con Ant, Groovy, tipos, orden por dependencia entre tareas(no dependiendo del ciclo de vida como en Maven).

Round 3: Ciclo de vida

El ciclo de vida de Maven tiene muchas etapas: validate, compile, test, package, integration-test, verify, install, deploy… mientras que el ciclo de vida de Gradle sólo tiene 3 fases: inicialización, configuración y ejecución.

Round 4: Scripting

Realizar scriping en maven es un infierno y si quieres utilizarlo acabas embebiendo código en el xml. Sin embargo, en Gradle, el propio script es código con lo que puedes importar plugins o clases de utilidad ya creadas.

Round 5: Dependencias

Maven es la referencia en la gestión/distribución de dependencias y por ello Gradle delega en Maven/Ivy para gestionarlas, aunque hay que tener cuidado porque cambia la nomenclatura de los ámbitos.

Round 6: Soporte IDE

Maven ha ido añadiendo soporte para entornos como Nerbeans, Eclipse e IntelliJ y Gradle, a pesar de su corta vida, tiene ya soporte para Netbeans (aunque limitado), para Eclipse (STS) y también para IntelliJ.

Round 7: Multiproyecto

Mientas que en Maven se declara un pom.xml padre con los hijos y se hereda tanto la configuración como las propiedades, en Gradle se separa la declaración de hijos de las configuraciones de herencia.

Viendo este enfrentamiento coincido con las conclusiones de Mario de que Gradle tiene grandes ventajas y creo que puede ser una herramienta muy potente y de la que se puede sacar mucho provecho, así que espero tener más tiempo para profundizar en ella y mientras tanto agradezco a Mario que se haya preparado esta estupenda introducción.

Gracias a @albertovilches podéis ver el vídeo entero de la charla en estos enlaces: