El Gradle Kotlin DSL: build.gradle.kts

Gradle es la herramienta de construccion que compila tu codigo Kotlin, resuelve tus dependencias, ejecuta tus pruebas y empaqueta tu aplicacion. Historicamente describias todo esto en un archivo llamado build.gradle escrito en Groovy, un lenguaje dinamico de la JVM. Groovy es flexible y conciso, pero esa flexibilidad tiene un precio: el script de build practicamente no tiene tipos, asi que un metodo mal escrito o un nombre de propiedad incorrecto solo se descubre cuando el build realmente se ejecuta, y tu IDE poco puede ofrecer mas alla de suposiciones para el autocompletado. El Kotlin DSL cambia el nombre del archivo a build.gradle.kts y escribe la misma configuracion en Kotlin.

Como build.gradle.kts es Kotlin de verdad, toda la API de Gradle pasa a tener tipado estatico. Tu IDE (IntelliJ IDEA y Android Studio ofrecen el mejor soporte) puede autocompletar nombres de plugins, bloques de configuracion, metodos de dependencias y propiedades de tareas; subraya en rojo los errores tipograficos antes de que ejecutes nada; y con Ctrl/Cmd-clic saltas directo al codigo fuente o al KDoc de Gradle. Errores que antes aparecian como fallos cripticos en tiempo de ejecucion ahora se muestran como errores de compilacion normales con numeros de linea precisos. La contrapartida es que la primera configuracion tras un cambio es un poco mas lenta porque el script debe compilarse, pero Gradle cachea agresivamente el script compilado, asi que la edicion diaria sigue siendo rapida y la seguridad vale la pena.

Todo script de build en Kotlin DSL se organiza en torno a unos pocos bloques fundamentales. El bloque plugins {} declara que plugins de Gradle aplicar, como el plugin de Kotlin JVM o el plugin application; cada plugin aporta nuevas tareas y opciones de configuracion. El bloque repositories {} le indica a Gradle de donde descargar las dependencias, casi siempre mavenCentral() y a veces google() para Android. El bloque dependencies {} lista las librerias que tu proyecto necesita, agrupadas por configuracion: implementation para codigo de uso interno, api para dependencias que expones a quienes consumen tu modulo (disponible cuando se aplica el plugin java-library), y testImplementation para librerias solo de pruebas como JUnit o Kotest. Estos bloques son simples llamadas a funciones Kotlin con lambdas finales, y por eso el IDE las entiende tan bien.

Fijate en las pequenas diferencias de sintaxis frente a Groovy. El Kotlin DSL exige comillas dobles para las cadenas y parentesis alrededor de los argumentos, asi que una dependencia se escribe implementation("grupo:artefacto:version") en lugar del implementation 'grupo:artefacto:version' de Groovy. Las asignaciones usan un = claro (por ejemplo version = "1.0.0"), y las versiones de plugins se declaran con la llamada infija version("...") dentro de plugins {}. Estas reglas hacen el script algo mas verboso que Groovy en ciertos puntos, pero son precisamente lo que da al compilador la informacion suficiente para validarlo todo y potenciar el autocompletado.

Junto a build.gradle.kts hay otros dos archivos que conviene conocer. settings.gradle.kts es el punto de entrada del build: define el nombre del proyecto raiz y, en un build multi-modulo, lista cada subproyecto con include("..."). La forma moderna de gestionar las versiones de dependencias es un catalogo de versiones, un archivo TOML en gradle/libs.versions.toml que centraliza versiones, librerias y plugins en un solo lugar. Luego las referencias en build.gradle.kts mediante el accesor generado y con tipado seguro libs, por ejemplo implementation(libs.kotlinx.coroutines.core), de modo que subir una version ocurre en un unico archivo y el IDE autocompleta cada alias.

En resumen, el Kotlin DSL te da una descripcion del build escrita en el mismo lenguaje que tu aplicacion, con tipado seguro completo, soporte de refactorizacion y autocompletado. Para una persona que desarrolla en Kotlin elimina el cambio de contexto hacia un mundo Groovy sin tipos y convierte el script de build en una parte navegable y de primera clase del codigo. Los proyectos nuevos de Kotlin y Android se generan con el Kotlin DSL por defecto, y combinarlo con un catalogo de versiones es la configuracion recomendada para cualquier proyecto moderno con Gradle 8 y Kotlin 2.x.

// build.gradle.kts — a typical Kotlin JVM application module
plugins {
    kotlin("jvm") version "2.0.21"   // Kotlin JVM plugin, version via infix call
    application                        // adds the `run` task
}

repositories {
    mavenCentral()                     // where Gradle downloads dependencies from
}

dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0") // internal use
    testImplementation(kotlin("test")) // test-only dependency (JUnit-based)
}

application {
    mainClass = "com.example.MainKt"   // type-safe assignment with `=`
}

// settings.gradle.kts — the entry point of the build
rootProject.name = "my-app"   // names the root project

include("core", "web")         // declares two subprojects in a multi-module build

# gradle/libs.versions.toml — centralized version catalog
[versions]
kotlin = "2.0.21"
coroutines = "1.9.0"

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

[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }
# In build.gradle.kts: implementation(libs.kotlinx.coroutines.core) and alias(libs.plugins.kotlin.jvm)