Descripción técnica de Maven1

1.- Introducción En este artículo pretendía comparar Ant con Maven, pero según avanzaba llegué a la conclusión de que no se puede hacer una comparación justa: mientras que Ant es una herramienta de construcción, Maven es una herramienta de gestión de código fuente y que, por tanto, abarca una problemática mucho mayor. Es por eso que Ant, siendo la herramienta de facto de construcción de proyectos, parece tan... pobre al lado de Maven En general, compensa mucho más Maven que Ant, salvo en algún caso excepcional. Esto es debido a que Ant está mucho más centrado en la construcción del software, mientras que Maven está enfocado hacia el trabajo en equipo. Ant puede compensar en aquellos casos en los que se quiera tener control absoluto del proceso de construcción (y, aún así, se puede integrar una tarea Ant como si fuera un goal Maven...). Ant permite hilar mucho más fino a la hora de hacer el despliegue de la aplicación, pero a costa de ficheros de construcción muchísimo más grandes. Maven, por el contrario, simplifica enormemente el proceso de construcción y despliegue a cambio de seguir una estandarización en el modo de desarrollo. No hay nada que no se puede hacer con Maven que no se pueda hacer con Ant y viceversa, pero en el caso de Ant lleva mucho *mucho* más trabajo por delante. Maven en cambio permite a un desarrollador construir, probar y documentar sus proyectos java de un modo consistente y que se integra de modo transparente con el trabajo del resto de desarrolladores. El uso de Maven debería ser obligatorio en los proyectos en que se trabaje con un equipo de desarrolladores. Esta idea, dicha así, sin más ni más, puede sonar bastante sectaria, pero es que después de conocer a fondo ambas herramientas he llegado a esta conclusión y esto es lo que se pretende mostrar en este artículo, una descripción técnica de las posibilidades que ofrece Maven a partir de un rápido vistazo a lo que ofrece Ant

2.- Ant Ant∞ es una herramienta de construcción de dominio público. Hoy por hoy es la herramienta J2EE de construcción más usada y cualquier IDE que se precie se integra nativamente con este programa. Las ventajas más importantes son que •

es multiplataforma, ya que está escrito en Java

•

utiliza ficheros de construcción escritos en XML (build.xml), frente a la sintaxis críptica de make

•

puede extenderse fácilmente creando nuevas tareas a medida

El hecho de ser multiplataforma hace que Ant añada una primera capa de abstracción que aisla al desarrollador respecto a la máquina en que esté trabajando. Un mismo proyecto Ant se comportará igual en el ordenador de un desarrollador que en el entorno de producción: no hay que cambiar las rutas de ficheros, ni depender de un entorno de desarrollo concreto para montar una aplicación, ni hacer 300 cosas para realizar el proceso de construcción (se realiza todo con un solo clic)... Esta independencia se ve reforzada por el hecho de que el fichero de configuración está escrito en xml, lo que facilita muchísimo su legibilidad y por tanto el mantenimiento y la extensibilidad de las tareas del proyecto

1 Artículo publicado bajo una licencia creative commons attribution-shareAlike 2.5∞. El artículo original y unos cuantos artículos más pueden encontrarse en esta dirección: http://metaware-inc.wiki.mailxmail.com/J2EE

El fichero de construcción en Ant Ant busca por defecto el fichero build.xml en el directorio desde donde se ha invocado (puede cambiarse con la opción –buildfile). Este archivo contiene toda la información referente a las acciones que se realizan para la construcción de un proyecto: compilar, crear directorios, eliminarlos, hacer despliegues de aplicaciones, etc, etc, etc. Dichas acciones en el ámbito de Ant se conocen como tareas. Las tareas se agrupan en el fichero build.xml en bloques funcionales, llamados targets, que son los que se le pide a Ant que ejecute El fichero build.xml también indica las dependencias de unas acciones con otras, así como los pasos a seguir cuando se ejecuta una tarea. Cada fichero de construcción contiene un único proyecto, que se descompone en uno o más targets y éstas en 0 o más tareas. Un ejemplo de dicho fichero puede ser éste: Created tar holding dependencies

Otros ejemplos de cómo extender Maven 1.0 pueden ser el clásico Hello World Plugin∞ o este otro ejemplo de un proyecto J2EE "real"∞

Extendiendo Maven 2.0 Los plugins se desarrollan en Maven 2.0 principalmente a través de clases Java llamadas Mojos (Maven POJOs). Esta clase debe heredar de la clase org.apache.maven.plugin.AbstractMojo y lleva unas determinadas anotaciones que se usan para ver cuándo y cómo se ejecuta el plugin. En el sitio ejemplo se muestra el código de un "Hola Mundo!" con forma de plugin Maven 2.x que recoge un par de parámetro del fichero pom.xml para mostrarlos por pantalla package foo.bar.plugin; import org.apache.maven.plugin.AbstractMojo; import org.apache.maven.plugin.MojoExecutionException; /** * @goal holamundo * @description Muestra un "Hola mundo!" y un par de atributos */ public class HolaMojo extends AbstractMojo { /** * @parameter expression="${project.version}" */ private String version; [...] /** * @parameter expression="default_name" * @required */ private String nombre; [...] public void execute() throws MojoExecutionException { getLog().info("Hola mundo! plugin version " + version + " - nombre: " + nombre); } }

El fichero pom.xml del plugin quedaría del siguiente modo: 4.0.0 foo.bar.plugin maven-hola-plugin maven-plugin 1.0-SNAPSHOT Hola Mundo con version Maven Plugin org.apache.maven maven-plugin-api 2.0 foo.bar.plugin maven-hola-plugin

Facundio compile holamundo

Este pom.xml viene bastante completito y con varias cosas para fijarse y a tener en cuenta. En primer lugar, todo plugin de Maven debe tener bien definidos los siguientes atributos en su POM: •

groupId: debe coincidir con el paquete de los Mojos

•

artifactId: nombre del plugin

•

version: versión del plugin

•

packaging: debería estar puesto a maven-plugin

•

dependencies: la dependencia maven-plugin-api tiene que estar declarada para poder resolver las clases AbstractMojo y allegadas

También se puede observar que se le pasa al Mojo el valor "Facundio" para el atributo nombre. Dicho atributo está declarado como obligatorio, por lo que en la anotación se le ha añadido un valor por defecto (default_name) y así evitar errores. El atributo version también es obligatorio, pero esta vez se ha puesto que por defecto se traiga el valor puesto en el POM. Hay una guía explicando cómo pasar los distintos tipos de valores a un Mojo para configurar un plugin aquí∞ Otro dato a tener en cuenta es que este Mojo se ejecutará cuando se ejecute la fase compile del build lifecycle∞, paso opcional que se hace solo para mostrar las distintas posibilidades de extensión que ofrece Maven. De este modo se conseguiría un equivalente al scripting hecho con Jelly en Maven 1.0 Para ejecutar un Mojo cualquiera de Maven se llama al goal que se quiere ejecutar usando su nombre completamente cualificado, con la forma: groupID:artifactID:version:goal, lo que para el ejemplo descrito se traduce en escribir en línea de comandos lo siguiente: "mvn foo.bar.plugin:maven-holaplugin:1.0-SNAPSHOT:holamundo" Esto es muy largo de escribir, y por ello existe un modo de acortarlo, que empieza por instalar el plugin con la opción updateReleaseInfo puesta a true, es decir: "mvn -DupdateReleaseInfo=true install". Después de esto hay que añadir el groupID del plugin a la lista de groupIDs buscados por defecto; para conseguirlo hay que añadir una línea en la sección en el fichero settings.xml. En este caso concreto, quedaría así: [...] [...] foo.bar.plugin [...] [...]

Hecho todo esto ya podríamos ejecutar "mvn hola:holamundo". La lógica de resolución del prefijo viene detallada en este documento∞

5.- Comparación de características de Ant y Maven Ant

Maven

Instalación

Muy fácil

Muy fácil

Tiempo para empezar un

5 minutos

proyecto nuevo

1 minuto (mediante el plugin genapp en Maven 1.0 o mediante el plugin archetype en Maven 2.0)

Tiempo que se tarda en añadir una nueva funcionalidad

Tiempo de aprendizaje de la herramienta

Estructura estándar en los proyectos

Soporte para Multi-Projects

10 minutos para añadir un target nuevo

30 minutos

2 horas

No

Sí

Sí, pero es complicado de implementar

Generación de

No, pero hay muchas herramientas

documentación

disponibles para ello

Integración con IDEs

2 minutos en usar un goal nuevo

Sí, está orientado a ello

Sí

Sí, en casi todos, por no decir en

A través del plugin Mevenide, en

todos (o por lo menos en cualquier

Eclipse, Netbeans, JBuilder e IntelliJ

IDE que se precie)

IDEA

Como se comentó al principio del artículo, una comparación de Maven con Ant nunca será del todo acertada, ya que Maven abarca una funcionalidad mucho mayor que la que pretende Ant. De todos modos, si se quiere comparar Maven con algo, se puede consultar esta otra tabla∞ donde se comparan las características de Maven 2.x con las de otros productos similares

6.- Bibliografía y artículos utilizados •

Automatizar la integración continua: una buena práctica∞

•

Configuración de plugins en Maven 2.x∞

•

Continuous Integration∞ por Martin Fowler

•

Entrada en la Wikipedia sobre Martin Fowler∞

•

Comparación de las características de Maven 2.x con otros productos∞

•

Guía para usar Maven 2.x en Eclipse∞

•

Introduction to the build lifecycle in Maven 2.x∞

•

Introducción a la resolución de prefijos en los plugins de Maven 2.x∞

•

Introducción a Maven 2∞

•

Mastering J2EE Application Development - Step 2: Managing J2EE Projects ∞

•

Maven Magic∞ Ejemplo de un proyecto J2EE "real" usando Maven

•

Maven 1.0 Hello World Plugin∞

•

Maven 2.x java plugin development∞

•

Maven 2.0 Enterprise Peace of Mind Is All Part of the Package∞ Tutorial bastante completo sobre Maven 2.0

•

Small releases in XP programming∞

•

What is Maven?∞