¿Por qué deberías pensar en Gradle 3.0 como sustituto de Maven?

¿Por qué deberías pensar en Gradle 3.0 como sustituto de Maven?
Sin comentarios Facebook Twitter Flipboard E-mail

Hace unas semanas el equipo de Gradle presentó la esperada versión 3.0 de esta herramienta open source de construcción de software. Aunque en el mundo Java el lider lleva siendo durante mucho tiempo Maven ya es hora de dejar atrás los interminables archivos XML de configuración y dar el paso algo más moderno y potente como Gradle.

En este artículo veremos las principales novedades de la versión 3.0 que puede que os den el empujón que falta para que migreis de Maven a Gradle.

Principales novedades

La principal novedad de Gradle 3.0 y que ha hecho correr ríos de tinta y rants por todo internet desde su anuncio hace unos cuatro meses es la inclusión de Kotlin como lenguaje adicional para escribir los archivos de build. Hablaremos de ello más adelante porque merece un capítulo aparte.

Incremento de la velocidad de las builds

El equipo de Gradle ha conseguido que las builds sean hasta un 75% más rápidas. Para ello ha optimizado y mejorado el _daemon_ que ahora está habilitado por defecto. El daemon se encarga de lanzar una JVM en segundo plano con todo el grafo de tareas y dependencias cargado en memoria de tal forma que cuando ejecutamos alguna otra tarea no tenemos que _pagar_ el precio de arrancar de nuevo una JVM y resolver otra vez toda la configuración. Adicionalmente se han centrado en corregir los bugs más importantes especialmente en plataformas Windows.

Soporte para Java 9

Gradle ya funciona con las últimas versiones EAP de Java 9 por lo que los usuarios ya pueden construir su software y ejecutar sus tests utilizando estas primeras versiones EAP del JDK 9.

Build on the cloud

Con la aplicación de un sencillo plugin podemos hacer que Gradle capture el resultado de nuestras builds y las publique en _Gradle Cloud Services_. Esto que a priori puede parece simplemente una web en la que publicamos el resultado de nuestra build, esconde mucho más cuando lo analizamos con detalle.
Podremos desde tener información detallada de cada build, ver por qué ha fallado o hasta compartir toda su información con cualquier miembro del equipo simplemente compartiendo el enlace. Adicionalmente tendremos un histórico de todas las builds del proyecto, podremos comparar entre ellas para encontrar problemas de rendimiento e incluso la propia herramienta nos sugerirá ajustar diversas opciones para conseguir que nuestras builds sean más rápidas.

Creo que la mejor forma de entenderlo es viendo los videos de apenas un minuto que se encuentran disponibles en su web y que explican con detalle todas estas caracterísiticas.

Si teneis curiosidad en ver cómo son los resultados de estas builds, aquí están disponibles algunos informes de Groovy, Grails o el propio Gradle.

Mejor soporte para los IDEs: Kotlin

Como he comentado anteriormente la novedad más importante de esta versión es la inclusión de Kotlin como lenguaje soportado para escribir nuestras builds. La principal ventaja que aporta Kotlin respecto a Groovy a la hora de escribir los archivos de build es que, al ser un lenguaje estático, el soporte en los IDEs es mucho más completo teniendo auto-completado de código, refactors y otras características que podrías esperar al utilizar un IDE.

Para los que piensen que Groovy está deprecado y pronto dejará de estar soportado en favor de Kotlin, esta es la respuesta oficial:

Groovy todavía es el lenguaje principal para escribir scripts de Gradle y siempre estará soportado

¿Qué aspecto tiene una build en Kotlin?

Un script de Gradle escrito en Kotlin no se diferencia mucho de uno escrito en Groovy.

import org.gradle.api.tasks.*

apply<ApplicationPlugin>()

configure {
    mainClassName = "org.gradle.samples.HelloWorld"
}

repositories {
    jcenter()
}

dependencies {
    compile("commons-lang:commons-lang:2.4")
    testCompile("junit:junit:4.12")
}

task("copyConfig") {
    from("src/main/conf")
    into("build/conf")
    exclude("**/*.old")
    includeEmptyDirs = false
}

Vemos que la forma de aplicar un plugin, definir el punto de entrada de la aplicación, la declaración de las dependencias o los distintos pasos dentro de una tarea de tipo _Copy_ son más verbosas que con Groovy, pero tampoco mucho más distintas. También es cierto que Groovy es especialmente muy buen lenguaje para la creación de DSLs.

Otras mejoras

Además de las novedades ya comentadas, hay otros muchos cambios que mejorarán notablemente tu experiencia con Gradle si decides actualizar:

  • Ejecución paralela de tareas: Ahora es más fácil definir y ejecutar tareas en paralelo en distintos workers.
  • Mejorado el DSL de plugins: Podemos definir plugins sin necesidad de aplicarlos al proyecto, por ejemplo para reutilizar sólo alguna de sus tareas o para aplicarlo sólo a los subproyectos.
  • Mejoradas las builds incrementales: Gradle 3.0 es capaz de reconocer no sólo cambios en las entradas y salidas de una tarea sino también los cambios en la propia tarea.
  • Resolución de dependencias más rápida: Resolver las dependencias ya descargadas es ahora entre un 5 y un 10% más rápido que en versiones anteriores.
  • Mejorado el soporte en Eclipse: El soporte de Gradle en Eclipse se ha mejorado notablemente y se han resuelto antiguos problemas existentes con la forma de definir las dependencias.

¿Cómo profundizar más?

Si te has quedado con ganas de aprender más sobre Gradle, en su propia web podrás obtener de manera totalmente gratuita algunos libros para seguir profundizando y aprendiendo todos los secretos para dar el paso definitivo y adoptarlo como tu herramienta de build.

Más información | Gradle En Genbeta Dev | Diez tecnologías que los javeros amamos (o al menos hablamos bien de ellas)

Comentarios cerrados
Inicio