Saltar al contenido

Jugada por jugada: Personalizando Gradle con Plugins

Sección Introducción Transcripciones

¿Cuál es la arquitectura del plugin?
Soy Tim Berglund. He sido desarrollador por mucho tiempo, he sido usuario de Gradle durante los últimos cinco años, he escrito un par de libros sobre Gradle, he dado clases sobre él. Y lo que vamos a hacer hoy es ver cómo escribir un plugin personalizado. Ahora, hay mucha sutileza en esto. Por un lado, voy a mostrarles las API de Gradle. Vamos a elegir un dominio de ejemplo, una razón por la que necesitamos extender Gradle, y escribiremos algo de código usando las API de Gradle. A medida que lo hagamos, aprenderemos un poco sobre la filosofía de Gradle y su enfoque para construir. Hay un punto más sutil aquí sobre la extensión de Gradle: La manera en que debe pensar en su proceso de construcción y pensar en la personalización de su construcción como una actividad de desarrollo de software de primera clase. Déjenme darles un avance de los temas que vamos a cubrir. Empezaremos revisando la naturaleza de las construcciones, históricamente lo que las diferentes herramientas de construcción en el ecosistema de la JVM han pensado realmente sobre las construcciones y dónde encaja Gradle en ese mundo. Miraremos las diferentes arquitecturas de plugins que esas herramientas de construcción han soportado y, de nuevo, veremos dónde encaja la arquitectura de plugins de Gradle en ese continuo. Veremos algunos de los plugins de Gradle que ya existen y, créanme, este es un rico ecosistema. Si ya eres un usuario de Gradle, probablemente sepas esto. Si alguna vez has construido un programa de Java con Gradle, que es lo que la mayoría de la gente hace primero, ya has usado un plugin de Gradle. Hay plugins de Gradle que vienen empaquetados con Gradle, hay plugins de Gradle que son proporcionados por la comunidad de código abierto y vale la pena explorarlos. Pasaremos un poco de tiempo haciendo eso. Una vez que empecemos a pensar en algunas personalizaciones reales haciendo las cosas que Gradle no hace por defecto y que queremos que haga nuestra construcción, vamos a ver qué pasa. Vamos a ver la lógica imperativa entrar en nuestra construcción. Es muy fácil comenzar de esa manera. Un script de construcción de Gradle, como ya sabéis, es un código genial y puedes hacer todo tipo de cosas ahí. Muy flexible, muy rápido para empezar. Pero verás que esto se convierte en un problema en poco tiempo y se complica y queremos tener cuidado con la forma en que manejamos la lógica imperativa. Una gran parte de esa gestión va a ser el concepto de modelado de dominio. Una construcción de Gradle es, como dije, una pieza de código de primera clase. Es un software diferente a cualquier otro software que puedas escribir. Y la construcción en sí misma es un dominio que tenemos que modelar en ese código. Veremos que vamos a introducir otros tipos de objetos que no son parte del modelo de Gradle en nuestra construcción y vamos a modelarlos de una manera fácil de entender. Después de todo esto, finalmente echaremos un vistazo a la API real de los plugins de Gradle. El código con el que vamos a terminar no es tan malo, pero muchos de los pasos que tenemos que dar no son para nada obvios, así que vas a estar agradecido por el proceso de caminar a través de él, construyendo ese código pieza por pieza, y teniendo un ejemplo para mirar cuando hayas terminado. Finalmente, veremos cómo empaquetar y distribuir nuestro plugin. En las primeras etapas del desarrollo de un plugin, sólo quieres que todo sea local. Quieres ver tus cambios, quieres ser capaz de iterar muy rápidamente mientras exploras el dominio y averiguas cómo funcionan todas las APIs. Al final, esto es lo que vamos a querer publicar en el portal de plugins de Gradle para que sea muy fácil para otras personas acceder a él y obtener nuevas versiones a medida que las lanzamos en vivo. Así que como puedes ver hay mucho material para cubrir. Empecemos.

Jugada por jugada: Personalizando Gradle con Plugins
Jugada por jugada: Personalizando Gradle con Plugins