TheNEXUS

Los autores de este libro no tienen ningún interés en crear una disputa entre Apache Ant y Apache Maven, pero también somos conscientes del hecho de que la mayoría de las organizaciones tienen que tomar una decisión entre las dos soluciones estándar: Apache Ant y Apache Maven. En esta sección, comparamos y contrastamos las herramientas.

Ant sobresale en el proceso de construcción, es un sistema de construcción modelado después de make con objetivos y dependencias. Cada objetivo consiste en un conjunto de instrucciones que se codifican en XML. Hay una tarea copy y una tareajavac así como una tarea jar. Cuando se utiliza Ant, se suministran a Ant instrucciones específicas para compilar y empaquetar la salida. Mira el siguiente ejemplo de un archivo build.xml simple:

Un archivo build.xml de Ant simple.

<project name="my-project" default="dist" basedir="."> <description> simple example build file </description> <!-- set global properties for this build --> <property name="src" location="src/main/java"/> <property name="build" location="target/classes"/> <property name="dist" location="target"/> <target name="init"> <!-- Create the time stamp --> <tstamp/> <!-- Create the build directory structure used by compile --> <mkdir dir="${build}"/> </target> <target name="compile" depends="init" description="compile the source " > <!-- Compile the java code from ${src} into ${build} --> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile" description="generate the distribution" > <!-- Create the distribution directory --> <mkdir dir="${dist}/lib"/> <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file --> <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/> </target> <target name="clean" description="clean up" > <!-- Delete the ${build} and ${dist} directory trees --> <delete dir="${build}"/> <delete dir="${dist}"/> </target></project>

En este sencillo ejemplo de Ant, puedes ver cómo tienes que decirle a Antex exactamente qué hacer. Hay un objetivo de compilación que incluye la tarea javac que compila el código fuente en el directorio src/main/java al directoriotarget/classes. Tienes que decirle a Ant exactamente dónde está tu fuente, dónde quieres que se almacene el bytecode resultante, y cómo empaquetar todo esto en un archivo JAR. Aunque hay algunos desarrollos recientes que ayudan a que Ant sea menos procedimental, la experiencia de un desarrollador con Ant consiste en codificar un lenguaje procedimental escrito en XML.

Contraste el ejemplo anterior de Ant con un ejemplo de Maven. En Maven, para crear un archivo JAR a partir de alguna fuente Java, todo lo que hay que hacer es crear un simple pom.xml, colocar el código fuente en${basedir}/src/main/java y luego ejecutar mvn install desde la línea de comandos. El ejemplo de pom.xml de Maven que consigue los mismos resultados que el archivo Ant simple listado en A Simple Ant build.xml file se muestra enA Sample Maven pom.xml.

A Sample Maven pom.xml.

<project> <modelVersion>4.0.0</modelVersion> <groupId>org.sonatype.mavenbook</groupId> <artifactId>my-project</artifactId> <version>1.0</version></project>

Eso es todo lo que necesitas en tu pom.xml. Ejecutar mvn install desde la línea de comandos procesará los recursos, compilará el código fuente, ejecutará las pruebas unitarias, creará un JAR, e instalará el JAR en un repositorio local para su reutilización en otros proyectos. Sin modificación, puede ejecutar mvn sitey luego encontrar un archivo index.html en target/site que contiene enlaces a JavaDoc y algunos informes sobre su código fuente.

Es cierto que este es el proyecto de ejemplo más simple posible que contiene nada más que algo de código fuente y produce un simple JAR. Es un proyecto que sigue de cerca las convenciones de Maven y no requiere ninguna dependencia o personalización. Si quisiéramos empezar a personalizar el comportamiento, nuestro pom.xml va a crecer en tamaño, y en los proyectos más grandes se pueden ver colecciones de POM de Maven muy complejas que contienen una gran cantidad de personalización de plugins y declaraciones de dependencias. Pero, incluso cuando los archivos POM de tu proyecto se vuelven más sustanciales, contienen un tipo de información completamente diferente del archivo de construcción de un proyecto de tamaño similar usando Ant. Los POM de Maven contienen declaraciones: «Este es un proyecto JAR», y «El código fuente está en src/main/java». Los archivos de compilación de Ant contienen instrucciones explícitas: «Este es un proyecto», «El código fuente está en src/main/java», «Ejecute javac contra este directorio», «Ponga los resultados en target/classes», «Cree un JAR a partir de ….», etc. Donde Ant tenía que ser explícito sobre el proceso, había algo «incorporado» a Maven que simplemente sabía dónde estaba el código fuente y cómo debía ser procesado.

Las diferencias entre Ant y Maven en este ejemplo son:

Maven tiene inteligencia incorporada sobre las tareas comunes del proyecto en forma de plugins de Maven. Si quieres escribir y ejecutar pruebas unitarias, todo lo que tendrías que hacer es escribir las pruebas, colocarlas en ${basedir}/src/test/java, añadir una dependencia de prueba o TestNG o JUnit, y ejecutar mvn test. Si desea desplegar una aplicación web y no un JAR, todo lo que tendría que hacer es cambiar su tipo de proyecto a war y poner su docroot en${basedir}/src/main/webapp. Claro que puedes hacer todo esto conAnt, pero tendrás que escribir las instrucciones desde cero. En Ant, primero tendrías que averiguar dónde debería estar el archivo JAR de JUnit. Luego tendrías que crear un classpath que incluya el archivo JUnitJAR. Entonces le dirías a Ant dónde debería buscar el código fuente de las pruebas, escribirías un objetivo que compilara el código fuente de las pruebas a bytecode, y ejecutarías las pruebas unitarias con JUnit.

Sin tecnologías de soporte como antlibs e Ivy (incluso con estas tecnologías de soporte), Ant tiene la sensación de ser un c`ustom proceduralbuild. Un conjunto eficiente de POMs de Maven en un proyecto que se adhiere a las convenciones asumidas de Maven tiene sorprendentemente poco XML en comparación con la alternativa de Ant. Otro beneficio de Maven es la dependencia de los plugins de Maven ampliamente compartidos. Todo el mundo utiliza el plugin de Maven Surefire para las pruebas unitarias, y si alguien añade soporte para un nuevo marco de pruebas unitarias, puede obtener nuevas capacidades en su propia construcción con sólo aumentar la versión de un plugin de Maven en particular en el POM de su proyecto.

La decisión de utilizar Maven o Ant no es binaria, y Ant todavía tiene un lugar en una construcción compleja. Si tu construcción actual contiene algún proceso altamente personalizado, o si has escrito algunos scripts de Ant para completar un proceso específico de una manera específica que no se puede adaptar a los estándares de Maven, todavía puedes utilizar estos scripts con Maven. Ant está disponible como un plugin central de Maven. Los plugins personalizados de Maven pueden ser implementados en Ant, y los proyectos Maven pueden ser configurados para ejecutar scripts Ant dentro del ciclo de vida del proyecto Maven.