Introducción a Gradle en Java

Gradle es una herramienta de automatización de compilación para la JVM (y más allá) que compila tu código, ejecuta tus pruebas, gestiona las dependencias y empaqueta el resultado — todo guiado por un script de compilación que escribes en Groovy o Kotlin. Mientras Maven describe un proyecto con XML fijo, Gradle lo describe con código: un script de compilación que configura un grafo de tareas. Ese cambio a un modelo programable, junto con una caché de compilación incremental que omite trabajo ya realizado, es la razón por la que Gradle impulsa Android y muchos proyectos Java de gran escala.

Gradle vs. Maven

Ambas herramientas resuelven el mismo problema — compilaciones repetibles con dependencias gestionadas — pero con diferentes compromisos. Si ya conoces Maven, este es el mapa comparativo:

Ninguna es estrictamente mejor. La rigidez de Maven hace las compilaciones predecibles; la flexibilidad de Gradle permite expresar compilaciones complejas. Esta parte enseña Gradle; la introducción a Maven cubre el otro lado.

Un script de compilación Java mínimo

Un proyecto Java de Gradle consiste en un archivo build.gradle más una estructura de directorios convencional (src/main/java, src/test/java). Aplicar el plugin integrado java es lo que le enseña a Gradle cómo compilar, probar y empaquetar en un jar:

plugins {
    id 'java'
}

group = 'com.example'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.google.guava:guava:33.0.0-jre'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
}

El DSL de Kotlin (build.gradle.kts) expresa lo mismo con accesores con seguridad de tipos:

plugins {
    java
}

dependencies {
    implementation("com.google.guava:guava:33.0.0-jre")
    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")
}

Las tareas son la unidad de trabajo

Todo lo que hace Gradle es una tarea — compileJava, test, jar, build. Las tareas declaran dependencias sobre otras tareas, formando un grafo acíclico dirigido (DAG). Cuando ejecutas gradle build, Gradle recorre ese grafo y ejecuta cada prerequisito exactamente una vez, en orden. También puedes definir las tuyas propias:

task hello {
    doLast {
        println 'Hello from a custom Gradle task'
    }
}

task release {
    dependsOn 'build', 'hello'
}

El plugin java configura un grafo estándar para ti: classes depende de compileJava y processResources; jar depende de classes; test depende de classes y compileTestJava; y build depende de jar y test. Solicitar build ejecuta entonces todas ellas en orden de dependencias.

El wrapper y la línea de comandos

El Gradle Wrapper (gradlew / gradlew.bat) es un script incluido en el repositorio que descarga y ejecuta la versión exacta de Gradle que el proyecto requiere, para que los colaboradores no necesiten tener Gradle instalado globalmente:

./gradlew build          # compile, test, and package
./gradlew test           # run tests only
./gradlew clean build    # wipe outputs, then rebuild from scratch
./gradlew tasks          # list available tasks
./gradlew dependencies   # print the resolved dependency tree

Usar ./gradlew en lugar del gradle del sistema es la opción recomendada por defecto — hace que la compilación sea reproducible entre máquinas y en CI.

Un ejemplo práctico: un grafo de tareas, resuelto como lo hace Gradle

No hay Gradle disponible en el ejecutor de esta página, así que en lugar de una compilación real modelamos el motor central de Gradle en Java puro: un grafo de tareas con dependencias, resuelto en un orden de ejecución mediante una ordenación topológica — exactamente lo que hace Gradle cuando escribes gradle build. El segundo pasaje muestra cómo las tareas up-to-date se omiten, que es el truco de compilación incremental de Gradle.

Lo que hay que extraer de la ejecución:

• La compilación declara 7 tareas, pero nunca se especifica un orden manualmente — se solicita build y el grafo calcula el resto. Esa inversión (declarar dependencias, dejar que la herramienta las ordene) es el corazón del modelo de tareas de Gradle.
• El orden resuelto imprime primero compileJava y processResources, luego classes, jar, compileTestJava, test y finalmente build. Una tarea solo se ejecuta después de todas las tareas de las que depende, por eso la compilación precede al empaquetado y las pruebas preceden a build.
• classes se alcanza por dos caminos (a través de jar y a través de test) pero aparece una sola vez en el orden — el conjunto done garantiza que cada tarea se ejecute una única vez, igual que Gradle nunca recompila las mismas fuentes dos veces en una misma invocación.
• En la segunda ejecución, las tres tareas marcadas como up-to-date imprimen (UP-TO-DATE) y no se contabilizan; solo jar, compileTestJava, test y build muestran (EXEC). Esta es la compilación incremental de Gradle: las tareas cuyas entradas no han cambiado se omiten.
• La línea final reporta 4 of 7 tareas ejecutadas. Omitir el trabajo sin cambios es exactamente la razón por la que un segundo gradle build es mucho más rápido que el primero, y por qué la caché de compilación importa en proyectos grandes.

Qué cubre el resto de esta parte

Escribir scripts build.gradle reales, declarar y resolver dependencias desde Maven Central, aplicar y configurar plugins, definir tareas personalizadas y usar el wrapper en CI. El siguiente capítulo, Construyendo un proyecto Java con Gradle, configura un proyecto Java completo con Gradle desde un directorio vacío.

Práctica