Cómo usar Kotlin con Gradle [Kotlin DSL]

Desde siempre, Gradle ha utilizado el lenguaje Groovy para definir sus scripts.

Pero con la aparición de Kotlin, muchas cosas han cambiado, e incluso Gradle ha decidido dar soporte a este lenguaje.

La ventaja de Kotlin es que es un lenguaje estático, pero tiene una apariencia muy similar la de un lenguaje dinámico.

Esto implica que el compilador nos puede ayudar con el autocompletado, y a la vez el código que tenemos que escribir es muy cercano a lo que escribiríamos con Groovy.

Kotlin DSL es una pequeña variante de Kotlin que se puede usar para definir scripts, y es la que Gradle utiliza.

A efectos prácticos no necesitas saber mucho más, se usa igual que Kotlin.

Kotlin DSL está muy bien, pero las herramientas no acompañaban

Es cierto que hasta hace poco era muy difícil utilizar Kotlin DSL, especialmente en Android Studio, ya que la versión de IntelliJ que se usaba por debajo aún no estaba muy preparada para ello.

Pero desde Android Studio 4.0, las cosas han cambiado, y ahora el IDE funciona mucho mejor. En teoría ya tenemos soporte completo e integrado, así que vamos a ponerlo a prueba.

Cómo creamos un proyecto en Android studio usando Kotlin DSL

Pues la primera en la frente: no hay una forma de elegir que se cree el proyecto utilizando Kotlin en los archivos de Gradle.

La única forma de conseguirlo es creando un proyecto con Groovy y convertirlo.

Y aquí llega el segundo golpe de efecto: no hay forma de convertir los archivos automáticamente, te va a tocar hacerlo a mano.

Paso 1: Adapta los ficheros Gradle actuales a algo más parecido a Kotlin DSL

En Groovy se pueden escribir algunas expresiones de distintas formas. Por ejemplo, una función con un único argumento se puede escribir tanto con paréntesis como sin ellos:

classpath "com.android.tools.build:gradle:4.0.0"
classpath("com.android.tools.build:gradle:4.0.0")

Esto también sucede con las properties (nos podemos ahorrar el “=”). Además podemos usar comillas simples y dobles indistintamente.

Esto en Kotlin no pasa, así que vamos a sustituir todas las comillas simples por dobles, y a poner paréntesis en todos los sitios donde creamos que puede haber una llamada a una función.

Te recomiendo que hagas todos los cambios sobre un fichero y luego pases al siguiente, en vez de cambiarlos todos de golpe.

Un mismo proyecto puede mezclar archivos con Groovy y Kotlin DSL, y así te irás asegurando de que lo que llevas está bien.

No importa que ahora mismo esté perfecto, cuando cambiemos la extensión (los ficheros tendrán extensión .kts), podremos terminar de ajustar.

Paso 2: Convierte las llamadas a los plugins al nuevo estilo

Pasaríamos de tener esto:

apply plugin: "com.android.application"
apply plugin: "kotlin-android"

A tener esto:

plugins {
    id("com.android.application")
    id("kotlin-android")
}

Paso 3: Convierte los ficheros Gradle a KTS:

Lo único que hay que hacer es añadir la extension .kts al fichero.

A partir de este momento, el compilador va a ser tu amigo, verás que te da información detallada de los errores desde el propio Android Studio (por suerte, esto antes no pasaba).

En este punto te puedes parar a terminar de adaptar los ajustes del paso 1.

Paso 4: Reemplaza la forma de configurar los build types

Es un poco más enrevesado. En vez de usar:

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro"
        }
    }

Usaríamos:

    buildTypes {
        getByName("release") {
            isMinifyEnabled = false
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
        }
    }

Los cambios aquí son:

• release se sustituye por getByName("release")
• minifyEnabled es una property que se llama isMInifyEnabled
• se cambia la función proguardFiles para que use paréntesis,

Paso 5: Si usas la carpeta “libs”, haz este cambio

El código original:

implementation(fileTree(dir: "libs", include: ["*.jar"]))

Se convierte en:

implementation(fileTree("libs") { include(listOf("*.jar")) })

Paso 6: Cómo configurar las variables en Kotlin DSL

Hay muchas formas de hacer esto, pero la más sencilla a largo plazo es hacer uso de buildSrc. Esta es un módulo que se compilará previamente al resto del código, y podremos acceder a los elementos definidos allí desde los archivos de Gradle.

Para ello, crea la carpetabuildSrc, y dentro un archivo de Gradle de configuración, y el archivo donde vas a guardar las constantes, de esta forma:

Dentro de esta carpeta, build.gradle.kts tiene esta pinta:

plugins {
    `kotlin-dsl`
}

repositories {
    mavenCentral()
}

Y el fichero de Versions es así:

object Versions {
    const val kotlinVersion = "1.3.72"
}

Aquí podrías añadir todas las constantes que necesites, o incluso crear varios objetos para estructurar mejor las constantes.

Paso 7: Cómo declarar tareas

El código:

task clean(type: Delete) {
    delete rootProject.buildDir
}

Se convierte en:

tasks.register("clean", Delete::class) {
    delete(rootProject.buildDir)
}

Paso 8: Termina de configurar el resto de archivos

Nos queda settings.gradle:

include(":app")
rootProject.name = "Kotlin DSL"

Y con esto ya lo tendríamos.

Conclusión

Como ves, la migración no es nada sencilla, y esto era un proyecto muy simple.

La ventaja de esto es que a partir de este punto, el autocompletado nos ayudará mucho más con la tarea:

Sobre si usarlo o no, dependerá mucho de tu habilidad con Gradle y de cuánto partido vayas a sacarle.

Para proyectos que no hagan un uso extensivo de Gradle, la verdad que puede que no merezca mucho la pena el esfuerzo.

¿Y tú que opinas, te animas a usar Kotlin DSL en Gradle, o prefieres seguir con Groovy? Te leo en los comentarios.

Y si quieres saber qué más novedades nos ha traído Android Studio 4.0, grabé un vídeo sobre ello hace poco.