Abel Muiño

home

Apache Buildr con Alex Boisvert

26 Jan 2011

La última sesión del San Francisco Java User Group, a la que pude acudir gracias a que Nilistics me plantó en USA para un poco de face to face development, trató sobre esta herramienta de build.

Alex es un tipo majo. Dejó claro de entrada que no tiene ningún puesto chulo en Buildr… sólo se encarga del papeleo (ocupa la project management chair). Aun así­, está entre «la gente importante». Además se esforzó por entender mis preguntas en balbuceante inglés :-)

La presentación

Alex reutilizó su presentación (creo que de la java one) pero como yo no voy a muchos saraos, para mi era nueva.

Buildr surge como una alternativa a Maven2 para builds que necesitan operaciones complejas o no standard. Los impulsores estaban contentos con Maven1 por su capacidad para incluir scripting (mediante el uso de jelly), algo que no es tan simple en Maven2.

El tag line de Buildr en la presentación es «build like you code» y se adapta muy bien a lo que vimos. Buildr está construí­do sobre rake que utiliza ruby… lo que lo deberí­a hacer muy familiar para todos los que somos promiscuos con los lenguajes de programación.

Sobre esta estructura se crea un DSL especí­fico para proyectos java (si amigos, una herramienta en ruby para compilar java). El resultado es muy interesante… se puede utilizar require para utilizar módulos especí­ficos (por ejemplo, para proyectos scala) y de forma automática se definen las convenciones adecuadas.

require 'buildr/scala'

Como es habitual en ruby, el DSL no es más que código ruby… por lo que Buildr nos permite hacer trucos que no son sencillos con herramientas como ant o maven, dónde tendremos que implementar una nueva Task o Plugin… normalmente en un proyecto separado (y publicarlo en algún sitio para que esté disponible durante la build). Buildr lo mantiene todo junto, lo que es mucho más simple (pero no tan reusable).

Uno de los puntos más fuertes que he visto en buildr es su habilidad para saber qué necesita hacerse. Es muy hábil comparando timestamps y saltándose pasos del build cuando es posible. Cosas que se supone que el resto de herramientas tambien hacen… pero en Buildr me ha parecido mucho más rápido.

Sobre la velocidad… en la demo, buildr era fascinantemente rápido. No sé si el portátil era la leche o realmente es así­ de veloz. Una de las cosas que podrí­a estar ayudando es que Buildr puede ejecutarse sobre el intérprete nativo de ruby y sólo crea una máquina virtual java cuando es necesaria usando el ruby-java bridge. La otra opción es usar jruby… en este caso estaremos «pagando» el coste de arranque de la jvm en cada ejecución.

Obvia decirlo, pero Buildr es capaz de consumir artefactos en repositorios maven sin problemas.

Mi visión de buildr

Yo soy un usuario feliz de Maven. Comulgo con la mayor parte de sus ideas, su convención sobre configuración y su modelo de plugins… así­ que Buildr me aporta poco. No deja de ser otra herramienta «tipo make», basada en tareas con dependencias entre si… no muy diferente de Ant, excepto en que vuelve a usar un lenguaje de scripting en lugar de xml (lo que es una ventaja, francamente).

¡Aunque eso de poder ejecutar código de forma simple durante la build suena apetecible! No es que con maven no se pueda, es que es feo, ya que hay que declarar un plugin, asociar su ejecución a una fase… Veremos si el polyglot-maven nos ayuda en el futuro.

Por otra parte, Buildr proporciona mediante su DSL una extensibilidad muy similar a la que proporciona Maven con sus plugins.

Como con casi todas las herramientas basadas en scripting, «un gran poder conlleva una gran responsabilidad». La flexibilidad de Buildr le permite consumir repositorios maven, pero publicar artefactos en ellos es harina de otro costal. A dí­a de hoy no está bien resuelto (entre otras cosas porque Buildr no maneja el concepto de scopes de maven, así­ que es incapaz de generar la lista de dependencias automáticamente). Pero tampoco es muy complicado de conseguir (sólo es repetitivo… algo que hay que configurar en cada script).

En resumen… si maven no es para ti, quizá buildr encaje mejor con tu forma de pensar. Si eres usuario de ant, estúdialo atentamente. O quizá buildr cambie tu forma de ver las builds… merece la pena echarle un vistazo.