El camino de Gradle Script Kotlin hacia la 1.0

Hace cinco meses anunciamos la primera preview de Gradle Script Kotlin,
y creemos que ahora es un buen momento para revisar el progreso que ha
habido desde entonces. El camino hacia la 1.0 es ahora bastante más claro.
Así que echemos un vistazo a lo que llevamos ya recorrido, y lo que nos
queda por delante.

v0.1.0

Puede que recordéis cómo era el ejemplo <code class="highlighter-rouge">hello-world
de nuestra primera versión:

import org.gradle.api.plugins.* import org.gradle.script.lang.kotlin.* apply() configure { mainClassName = "samples.HelloWorld" } repositories { jcenter() } dependencies { "testCompile"("junit:junit:4.12") }

Algo incómodo ese import de <code class="highlighter-rouge">org.gradle.script.lang.kotlin.*!
Y ese <code class="highlighter-rouge">"testCompile" como cadena bastante poco amigable con los IDEs.
Y sin olvidarnos, para aquellos primeros valientes que pudieron probarla,
de las tareas <code class="highlighter-rouge">generateKtsConfig y <code class="highlighter-rouge">patchIdeaConfig que hacían falta
para que las builds basadas e Kotlin funcionasen en IDEA.

Pero a pesar de todo, el lenguaje de programación y la experiencia del IDE
era tan buena que ya nos tenía enganchados. Y en relación a las cosas por
pulir, ya íbamos viendo cómo refinarlas, lo que nos llevó a la versión
0.2.0 que liberamos un mes después.

v0.2.0

Con imports implícitos y una
alternativa amigable con el tooling para las configuraciones de dependencias, el <code class="highlighter-rouge">hello-world
de la 0.2.0 ya empezaba a ser bastante limpio y conciso.

apply() configure { mainClassName = "samples.HelloWorld" } repositories { jcenter() } dependencies { testCompile("junit:junit:4.12") }

Tener imports de proyectos sin costuras
significaba que las builds basadas en Kotlin en IDEA empezaban a funcionar de serie, y así
se acabaron los días de escribir mal <code class="highlighter-rouge">generateKtsConfig y <code class="highlighter-rouge">patchIdeaConfig.

Quizá más importante, la 0.2.0 introdujo soporte para dependencias de build scripts y plugins externos
que hizo que Gradle Script Kotlin fuese una opción viable para muchos proyectos reales.

v0.3.0

La 0.3.0 fue un hito mayor para el proyecto, ya que fue la primera versión incluída en una distribución
de Gradle. ¡En Gradle 3.0, ni más ni menos!

¡Y la 0.3.0 era todo sobre ese Kotlin!
El nuevo compilador 1.1-M01 de Kotlin,
soportando plugins basados en Kotlin y
directorios <code class="highlighter-rouge">buildSrc además de algo
de azúcar para esas primitivas de interoperabilidad Kotlin-Groovy:

gradle.buildFinished(closureOf { println("$action finished") // $action refers to BuildResult.getAction() })

Con Gradle 3.0 recién salido del horno, el canal #gradle del Slack de Kotlin público vio un incremento
en la participación que nos ayudó enormemente a priorizar los siguientes pasos.

<code class="language-kotlin" data-lang="kotlin">

v0.3.1

Nos dimos cuenta de que la gente peleaba con la falta de algo más de seguridad tipada y formas más
amigables con el IDE para configurar dependencias, así que con la 0.3.1
introdujimos un DSL para dependencias muy mejorado.

dependencies { default(group = "org.gradle", name = "foo", version = "1.0") { isForce = true } compile(group = "org.gradle", name = "bar") { exclude(module = "foo") } runtime("org.gradle:baz:1.0-SNAPSHOT") { isChanging = true isTransitive = false } testCompile(group = "junit", name = "junit") testRuntime(project(path = ":core")) { exclude(group = "org.gradle") } }

Actualizar a Kotlin 1.1-dev-2053 mejoró notablemente el rendimiento y la asistencia de código
dentro de IDEA gracias a un valioso miembro de la comunidad, y se publicó el primer
ejemplo de Script de Gradle hecho en Kotlin para Android.

v0.3.2

Con la 0.3.2 decidimos solucionar el temido problema del <code class="highlighter-rouge">it
via la generación en runtime de código de las extensiones de Kotlin.
¿Cuál es el temido problema del <code class="highlighter-rouge">it? Tomad el uso de <code class="highlighter-rouge">copySpec como ejemplo. Antes de la 0.3.2,
hubiésemos escrito:

copySpec { it.from("src/data") it.include("*.properties") }

La sintaxis no se leía muy bien, y nos alejaba un poco de la fluidez y legibilidad que el DSL de Gradle
ha mantenido siempre. Pero no temáis. Con la 0.3.2 el <code class="highlighter-rouge">it desapareció:

copySpec { from("src/data") include("*.properties") }

v0.3.3 and v0.4.0

La versión 0.3.3
y la 0.4.0
liberadas recientemente han traído consigo la primera
de una plétora de mejoras a las builds de multiproyectos
incluyendo la habilidad de definir lógica personalizada usando Kotlin en <code class="highlighter-rouge">buildSrc.

La 0.4.0 está disponible ya y estará incluída en la distribución de Gradle 3.2 que está por venir.

Hacia la v1.0.0

¿Qué es lo siguiente?, os preguntaréis. Y estas son algunas de las cosas destacadas de las próximas versiones en tres áreas clave:

1. Rendimiento: Configuraciones de proyectos más rápidas via cachés de build scripts compilados (#31)
2. Usabilidad: Accesores con seguridad tipada para extensiones y convenciones contribuidas por plugins (#159); Documentación exhaustiva (#106)
3. Conveniencia: Aplicación de plugins declarativ y amigable con herramientas (también conocidos como bloque <code class="highlighter-rouge">plugins) (#168)

Y con todo, así es como tenemos previsto que sea el ejemplo de <code class="highlighter-rouge">hello-world en Gradle Script Kotlin 1.0:

plugins { application } application { mainClassName = "samples.HelloWorld" } repositories { jcenter() } dependencies { testCompile("junit:junit:4.12") }

¿Cómo lo véis? Nos encantaría saber lo que pensáis.

Muchas gracias a todos los que habéis embarcado en esta aventura. Y a los que acabéis de uniros
a Gradle Script Kotlin, ¡bienvenidos!