Descripción técnica de Maven 1.- IntroducciónEn 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.- AntAnt∞ 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
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 El fichero de construcción en AntAnt 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: <?xml version="1.0" encoding="iso-8859-1" ?>
<project basedir="." default="all" name="test">
<property environment="env" />
<!-- borra el directorio build -->
<target name="clean">
<delete dir="build"/>
</target>
<!-- crea los directorios build/classes y build/lib -->
<target name="prepare">
<mkdir dir="build/classes" />
<mkdir dir="build/lib" />
</target>
<!-- define un grupo de archivos que pueden ser usados en el resto de tareas -->
<path id="jars">
<fileset dir="${env.CATALINA_HOME}/common/lib" includes="servlet.jar" />
</path>
<!-- compila las clases de la carpeta src y las deja en el directorio build/classes; posteriormente
monta un jar con todos los archivos .class que hay en build/classes y lo deja en build/lib -->
<target name="javac">
<javac classpathref="jars" destdir="build/classes" srcdir="src"/>
<jar destfile="build/lib/microf.jar" basedir="build/classes" includes="microf/**/*.class" />
</target>
<!-- ejecuta el resto de targets en el orden indicado -->
<target depends="clean, prepare, javac" name="all">
</target>
</project>Extendiendo AntPara ello se creará una clase que extienda la clase org.apache.tools.ant.Task. La ejecución de la tarea se implementa mediante un método execute que lanza una excepción BuildException en caso de error. Por cada atributo de la tarea se escribe un método setter. El tipo de atributo puede ser un tipo primitivo, String, File, Class o cualquier otro tipo que contenga un constructor con un único parámetro de tipo String. A continuación se muestra un ejemplo muy sencillo de una tarea Ant creada a medida: import org.apache.tools.ant.Task;
public class MyEcho extends Task {
private String message;
public void setMessage(String m) {
this.message= m;
}
public void execute() throws BuildException {
log(message);
}
}Por último se añade al sistema la nueva tarea, que puede hacerse o bien añadiendo un elemento <taskdef> al proyecto, o bien de manera permanente, añadiendo la tarea al fichero defaults.properties en el paquete org.apache.tools.ant.taskdefs. |