Qué es Gradle y por qué Kotlin lo usa

Gradle es una herramienta de automatización de compilación: toma tu código fuente y lo convierte en algo ejecutable o distribuible (un JAR, un APK de Android, un fat-jar de Spring Boot) orquestando cada paso intermedio — compilar Kotlin, procesar recursos, ejecutar pruebas y empaquetar el resultado. El ecosistema Kotlin se apoya en Gradle porque el Kotlin Gradle Plugin oficial es la forma canónica de compilar Kotlin para JVM, Android, Native y multiplataforma. En lugar de invocar el compilador a mano con una larga lista de flags y classpaths, declaras *qué* quieres en un script de build y Gradle averigua *cómo* producirlo, cacheando y omitiendo el trabajo que no ha cambiado.

Lo más valioso que ofrece Gradle es la gestión de dependencias. Declaras las librerías que tu proyecto necesita (por ejemplo una librería de corrutinas o de serialización) junto con una versión, y Gradle las descarga desde repositorios como Maven Central, resuelve sus dependencias transitivas y arma el classpath correcto para cada configuración — `implementation` para necesidades normales de compilación y ejecución, `testImplementation` para librerías solo de pruebas, etc. Esto significa que nunca subes archivos JAR a tu repo; subes una breve declaración y Gradle reproduce exactamente el mismo conjunto de artefactos en cualquier máquina.

Todo lo que hace Gradle se modela como un grafo de *tareas*. Una tarea es una unidad de trabajo con entradas y salidas — `compileKotlin`, `test`, `jar`, `build`. Las tareas declaran dependencias entre sí, así que cuando ejecutas `./gradlew build`, Gradle calcula el orden, ejecuta solo las tareas cuyas entradas cambiaron (builds incrementales) y puede reutilizar resultados de una caché de build. Al principio rara vez escribes tareas a mano; plugins como `kotlin("jvm")` o `application` registran un conjunto completo de tareas por ti, y tú simplemente las configuras.

Los proyectos Kotlin usan el DSL de Kotlin para los scripts de build, por lo que los archivos terminan en `.kts` y están escritos en el propio Kotlin — dándote seguridad de tipos y autocompletado en el IDE en lugar de la sintaxis dinámica de Groovy. Hay dos archivos distintos. `settings.gradle.kts` es el punto de entrada a nivel de proyecto: nombra el proyecto raíz y declara qué subproyectos (módulos) pertenecen al build mediante `include(...)`, y también es donde configuras desde dónde se descargan plugins y dependencias. `build.gradle.kts` es por módulo: aplica plugins, define el toolchain de Kotlin/JVM y declara las dependencias y la configuración de tareas de ese módulo. Un proyecto de un solo módulo sigue teniendo uno de cada; un proyecto multimódulo tiene un `settings.gradle.kts` y un `build.gradle.kts` en cada módulo.

El Gradle Wrapper (`gradlew` en macOS/Linux, `gradlew.bat` en Windows) es lo que hace que un build sea verdaderamente reproducible entre máquinas. El wrapper es un pequeño script versionado más `gradle/wrapper/gradle-wrapper.properties`, que fija la versión exacta de Gradle. Cuando un compañero ejecuta `./gradlew build`, el wrapper descarga esa versión precisa de Gradle (si falta) y la ejecuta — así nadie necesita Gradle instalado globalmente y todos compilan con el mismo motor idéntico. La regla de oro: invoca siempre `./gradlew`, nunca un `gradle` del sistema, y sube los archivos del wrapper al control de versiones.

Gradle moderno (8.x en adelante) también promueve un *catálogo de versiones*: un archivo `gradle/libs.versions.toml` que centraliza las coordenadas y versiones de dependencias en un solo lugar. En lugar de esparcir cadenas de versión por muchos `build.gradle.kts`, las defines una vez y las referencias como accesores con tipos — `libs.kotlinx.coroutines` para una librería, o `alias(libs.plugins.kotlin.jvm)` para un plugin. Esto mantiene las versiones consistentes entre módulos y convierte las actualizaciones en un cambio de una sola línea. En conjunto — el DSL de Kotlin, el wrapper y el catálogo de versiones — te dan builds tipados, reproducibles y fáciles de mantener. Recuerda: los builds de Gradle no se ejecutan dentro de esta lección en el navegador, así que trata estos snippets como plantillas de referencia precisas para copiar a un proyecto real.

// settings.gradle.kts — names the build and declares its modules
rootProject.name = "my-kotlin-app"

// The type-safe version catalog at gradle/libs.versions.toml is auto-detected
include(":app", ":core") // each becomes a module with its own build.gradle.kts

// build.gradle.kts (module) — applies plugins and declares dependencies
plugins {
    alias(libs.plugins.kotlin.jvm)    // Kotlin Gradle Plugin, version from the catalog
    application                       // adds the `run` task
}

kotlin {
    jvmToolchain(21)                  // compile/run against JDK 21
}

repositories { mavenCentral() }       // where dependencies are fetched from

dependencies {
    implementation(libs.kotlinx.coroutines) // catalog accessor, not a raw string
    testImplementation(kotlin("test"))      // test-only dependency
}

application { mainClass = "com.example.AppKt" }

# gradle/libs.versions.toml — centralized versions and dependency coordinates
[versions]
kotlin = "2.1.0"
coroutines = "1.9.0"

[libraries]
kotlinx-coroutines = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }

[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }