Gradle
Gradle es una herramienta de gestión de software, que copia y combina las partes de Ant y Maven, construyendo encima de ellas con DSL y otras mejoras.
Tiene la potencia de Ant, así como la flexibilidad del ciclo de vida de Maven, y es fácil de usar. El resultado final es una herramienta que se publicó en 2012 y ganó mucha atención en un período corto de tiempo. Por ejemplo, Google adoptó Gradle como la herramienta de construcción por defecto para Android OS.
Gradle no usa XML. En su lugar, tiene su DSL basado dentro de Groovy (uno de los lenguajes de la JVM). Como resultado, Gradle contruye scripts muchos más cortos que aquellos construidos con Ant o Maven. La cantidad de código es mucho más pequeño con Gradle, desde que su DSL esta diseñado para resolver problemas específicos: mover software a través de su ciclo de vida, desde compilar a través de análisis estáticos y testear, empaquetar y desplegar.
Inicialmente, Gradle usó Apache Ivy para su gestión de dependencia. Posteriormente movió su ingeniería de resolución de dependencias a una propia nativa.
Un ejemplo de fichero de configuración es el siguiente:
description = 'Tapestry Project'
version = '0.0.1'
apply plugin: 'eclipse'
apply plugin: 'java'
apply plugin: 'groovy'
apply plugin: 'war'
// Propiedades de configuración
//Eclipse
downloadJavadoc = true
// Java
sourceCompatibility = 1.6
repositories {
flatDir name: 'Local', dirs: 'misc/lib'
mavenRepo name: 'Apache (Staging)', url: 'https://repository.apache.org/content/groups/staging/'
mavenRepo name: 'JBoss', url: 'https://repository.jboss.org/nexus/content/repositories/releases/'
mavenRepo name: 'Java', url: 'http://download.java.net/maven/2/'
mavenCentral()
}
dependencies {
compile 'org.apache.tapestry:tapestry5-annotations:5.3.2'
compile 'org.apache.tapestry:tapestry-core:5.3.2'
compile 'org.apache.tapestry:tapestry-beanvalidator:5.3.2'
compile 'org.apache.tapestry:tapestry-hibernate-core:5.3.2'
compile 'org.apache.tapestry:tapestry-hibernate:5.3.2'
compile 'org.apache.tapestry:tapestry-func:5.3.2'
compile 'org.apache.tapestry:tapestry-ioc:5.3.2'
compile 'org.apache.tapestry:tapestry-javadoc:5.3.2'
compile 'org.apache.tapestry:tapestry-jmx:5.3.2'
compile 'org.apache.tapestry:tapestry-json:5.3.2'
compile 'org.apache.tapestry:tapestry-test:5.3.2'
compile 'org.apache.tapestry:tapestry-upload:5.3.2'
compile 'org.apache.tapestry:tapestry-yuicompressor:5.3.2'
compile 'org.hibernate:hibernate-core:3.6.8.Final'
compile 'org.hibernate:hibernate-ehcache:3.6.8.Final'
compile 'org.hibernate:hibernate-validator:4.2.0.Final'
compile 'org.quartz-scheduler:quartz:2.1.0'
compile 'org.freemarker:freemarker:2.3.18'
compile 'org.apache.commons:commons-lang3:3.0'
providedCompile 'javax.servlet:servlet-api:2.5'
providedCompile 'javax.mail:mail:1.4.4'
groovy 'org.codehaus.groovy:groovy-all:1.8.3'
// Test
testCompile 'junit:junit:4.8.2'
testCompile 'net.sourceforge.htmlunit:htmlunit:2.9'
testCompile 'org.mockito:mockito-all:1.9.0'
}
El nº de líneas de este fichero, es mucho menor que el nº de líneas que ocuparía el POM de Maven.
Por otro lado, en Ant, tenemos el problema de que no se desarrolló pensando en hacer uso de repositorios externos que gestionarán las librerías, aunque con Ivy podríamos suplir esta carencia. Maven añadió esta característica, y Gradle, parece, aprende de ambos, e introduce mejoras: menor cantidad de líneas por fichero.
La primera ventaja que se puede ver es que el fichero de configuración es más manejable, es cierto que, en caso de ficheros grandes, esto es una ventaja. Además, permitiría la edición sencilla desde un editor de texto plano, sin necesidad de depender de herramientas visuales para mejorar su gestión, que cargan la memoria del sistema.
Por otro lado, en otros enlaces de la web, se indica lo siguiente: desde un proyecto de Maven no es posible generar dos jars diferentes, esto obliga a que, para ello, tengas que definir dos proyectos de Maven, lo cual hace la estructura rígida (me hace pensar que considerar a Maven rígido, es ciertamente que el nivel de frikismo, en el buen sentido, de Graddle supera las expectativas conservadoras que he ido desarrollando en mi vida profesional). Graddle parece más flexible en ese sentido.
¿Qué es DSL?
Lenguaje específico de dominio (DSL) basado en Groovy en lugar de la forma más tradicional de declarar la configuración del proyecto con XML
Gradle effort can be summed as “convention is good and so is flexibility”.
Gradle
Reader Comments (5)
Gradle por méritos propios se ha convertido en la herramienta capaz de reemplazar Ant y Maven ofreciendo las ventajas expuestas aquí y en el artículo original Herramienta de construcción Gradle del ejemplo en el que comento alguna cosa más.
En la antigua empresa donde prestaba servicios realizaba mantenimientos en proyectos concebidos con ANT como mecanismo de compilación (de entrometido pues no era mi área, pero es que la gestión de configuración me puede). No puedo negar su flexibilidad pero para la gestión de dependencias tuve que apoyarme en Apache Ivy y la verdad no me fue tan mal. Pero Gradle es otra cosa, ya se olía algo cuando JBoss y Springsource migraron parte de sus proyectos a este mecanismo. Terminamos utilizando un ci (TeamCity) y los proyectos que lo permitieron se migraron a Gradle junto con los nuevos que empezaban, no hay color señores, un acierto en toda regla esta herramienta.
¡Muchas gracias por vuestras opiniones!
Decir que con Maven no se puede generar dos jars distintos y que hay que tener 2 proyectos es desconocer totalmente Maven.
Desde hace tiempo Maven incorpora el concepto de profile y se utiliza por ej. si uno quisiera construir 2 wars con configuraciones distintas (por ej. desarrollo y producción).
Por otro lado poner que Gradle es mejor porque ocupa menos y se puede abrir el archivo como texto plano.....
Pareciera que nos preocupamos por las cosas que deberían pasar desapercibidas.
Prefiero un archivo bien grande y que sea fácil de leer (con un buen editor) a uno chiquito y que no se entienda (y con esto no quiero decir que Gradle no se entienda)
Me hubiera gustado que en las notas expusieran algo de las diferencias entre ambos y qué cosas agrega Gradle que con Maven no se pueden o son muy difíciles.
Saludos
Hola Diego, gracias por el aporte.
Contestamos a tus comentarios y mencionamos más cosas.
1) Graddle es más flexible, no es obligatorio pasar por todos los ciclos de vida, como pasa en Maven, para hacer uso de un jar del que dependerá otro proyecto. Maven define buenas prácticas, pero las hace axioma, y eso puede frustrar (por ejemplo, para hacer uso de un jar en un proyecto padre, requiere que el jar hijo sea instalado en el repositorio)...
Otro ejemplo sencillo sobre la flexibilidad, puedes definir múltiples directorios fuente o de test en un mismo proyecto, cuando en Maven parece que no puedes hacerlo (por rigidez).
2) Ya se vio que Graddle es más conciso, para mí este punto no tiene debate (salvo la posible resistencia al cambio). A mi entender, más información en menos espacio implica mayor manejabilidad.
3) Sobre parametrización de Maven, puedes hacer uso de la misma, pero no me expliqué bien, imagina que quieres crear un cliente y un servidor de un mismo proyecto, tienes la opción de crear un proyecto pom con las clases comunes y luego un pom cliente que dependa de este primero así como un pom servidor. Parece mucho jaleo.... Porque utilizar parametrización en este ejemplo no sería buena idea, pues saltas el ciclo de vida de Maven. La parametrización que comentas a mi modo de ver está bien para ficheros finales, como war's de desarrollo y producción que comentas, pero no para jar's que podrían ser utilizados por otros proyectos, como un cliente o un servidor de servicios web, que podrían construirse a partir de un mismo proyecto, y utilizarse por terceros, en este caso, sería obligatorio, según Maven, definir un proyecto por cada uno de ellos.... o bien saltarte el propio ciclo de vida de Maven (usar parametrización para generar los jars y posteriormente copiar los mismos de manera manual en terceros proyectos).
Un saludo,