Diferencias entre Ant y Maven [cerrado]

¿Alguien podría decirme las diferencias entre Ant y Maven? Nunca he usado tampoco. Entiendo que se utilizan para automatizar la construcción de proyectos Java, pero no sé por dónde empezar.

En Maven: The Definitive Guide , escribí sobre las diferencias entre Maven y Ant en la introducción, el título de la sección es "Las diferencias entre Ant y Maven" . Aquí hay una respuesta que es una combinación de la información en esa introducción con algunas notas adicionales.

Una comparación simple

Solo te muestro esto para ilustrar la idea de que, en el nivel más básico, Maven tiene convenciones incorporadas. Aquí hay un archivo de compilación 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, puede ver cómo debe decirle a Ant exactamente qué hacer. Hay un objetivo de compilación que incluye la tarea javac que compila la fuente en el directorio src / main / java en el directorio target / classes. Tiene que decirle a Ant exactamente dónde está su fuente, dónde desea que se almacene el bytecode resultante y cómo empaquetar todo esto en un archivo JAR. Si bien hay algunos desarrollos recientes que ayudan a que Ant sea menos procesal, la experiencia de un desarrollador con Ant es codificar un lenguaje de procedimiento escrito en XML.

Contraste el ejemplo anterior de Ant con un ejemplo de Maven. En Maven, para crear un archivo JAR de alguna fuente Java, todo lo que necesita hacer es crear un pom.xml simple, colocar su código fuente en $ {basedir} / src / main / java y luego ejecutar mvn install desde la línea de comandos . El ejemplo Maven pom.xml que logra los mismos resultados.

<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. La ejecución de mvn install desde la línea de comandos procesará recursos, compilará la fuente, ejecutará pruebas unitarias, creará un JAR e instalará el JAR en un repositorio local para su reutilización en otros proyectos. Sin modificaciones, puede ejecutar mvn site y luego encontrar un archivo index.html en target / site que contenga enlaces a JavaDoc y algunos informes sobre su código fuente.

Es cierto que este es el proyecto de ejemplo más simple posible. Un proyecto que solo contiene código fuente y que produce un JAR. Un proyecto que sigue las convenciones de Maven y no requiere ninguna dependencia o personalización. Si quisiéramos comenzar a personalizar el comportamiento, nuestro pom.xml crecerá en tamaño, y en el mayor de los proyectos puede ver colecciones de POM Maven muy complejos que contienen una gran cantidad de personalización de complementos y declaraciones de dependencia. Pero, incluso cuando los archivos POM de su proyecto se vuelven más importantes, contienen un tipo de información completamente diferente del archivo de compilación de un proyecto de tamaño similar que utiliza 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 Ant contienen instrucciones explícitas: "Este es el proyecto", "src/main/java"," Ejecutar javaccontra este directorio "," Poner los resultados en target/classses"," Crear un JAR desde ... ", etc. Cuando Ant tenía que ser explícito sobre el proceso, había algo" incorporado "en Maven que solo sabía dónde estaba el código fuente y cómo debería procesarse.

Comparación de alto nivel

¿Las diferencias entre Ant y Maven en este ejemplo? Hormiga...

• no tiene convenciones formales como una estructura de directorio de proyecto común, debe decirle a Ant exactamente dónde encontrar la fuente y dónde colocar la salida. Las convenciones informales han surgido con el tiempo, pero no se han codificado en el producto.
• es de procedimiento, tienes que decirle a Ant exactamente qué hacer y cuándo hacerlo. Tenías que decirle que compilara, luego copiara y luego comprimiera.
• no tiene un ciclo de vida, tenía que definir objetivos y dependencias de objetivos. Debía adjuntar una secuencia de tareas a cada objetivo manualmente.

Donde Maven ...

• tiene convenciones, ya sabía dónde estaba su código fuente porque siguió la convención. Puso el bytecode en target / classes, y produjo un archivo JAR en target.
• es declarativo Todo lo que tenía que hacer era crear un archivo pom.xml y colocar su fuente en el directorio predeterminado. Maven se encargó del resto.
• tiene un ciclo de vida, que invocaste cuando ejecutaste mvn install. Este comando le dijo a Maven que ejecutara una serie de pasos de secuencia hasta que alcanzara el ciclo de vida. Como efecto secundario de este viaje a través del ciclo de vida, Maven ejecutó una serie de objetivos de complementos predeterminados que hicieron cosas como compilar y crear un JAR.

¿Qué hay de Ivy?

Bien, entonces alguien como Steve Loughran leerá esa comparación y llamará falta. Él va a hablar sobre cómo la respuesta ignora por completo algo llamado Ivy y el hecho de que Ant puede reutilizar la lógica de compilación en los lanzamientos más recientes de Ant. Esto es verdad. Si tienes un montón de personas inteligentes que usan Ant + antlibs + Ivy, terminarás con una compilación bien diseñada que funciona. Aunque estoy muy convencido de que Maven tiene sentido, felizmente usaría Ant + Ivy con un equipo de proyecto que tenía un ingeniero de construcción muy inteligente. Dicho esto, creo que terminarás perdiendo varios complementos valiosos como el complemento Jetty y que terminarás haciendo un montón de trabajo que no necesitas hacer con el tiempo.

Más importante que Maven vs. Ant

1. Es que utiliza un Administrador de repositorio para realizar un seguimiento de los artefactos de software. Sugeriría descargar Nexus . Puede usar Nexus para proxy repositorios remotos y proporcionar un lugar para que su equipo implemente artefactos internos.
2. Tiene una modularización adecuada de los componentes del software. Un gran componente monolítico rara vez se escala con el tiempo. A medida que su proyecto se desarrolle, querrá tener el concepto de módulos y submódulos. Maven se presta a este enfoque muy bien.
3. Adoptas algunas convenciones para tu construcción. Incluso si usa Ant, debe esforzarse por adoptar alguna forma de convención que sea consistente con otros proyectos. Cuando un proyecto usa Maven, significa que cualquiera que esté familiarizado con Maven puede retomar la compilación y comenzar a ejecutarla sin tener que manipular la configuración solo para descubrir cómo hacer que se compile.

Maven es un marco, Ant es una caja de herramientas

Maven es un automóvil de carretera prefabricado, mientras que Ant es un conjunto de piezas de automóviles. Con Ant, debe construir su propio automóvil, pero al menos si necesita conducir fuera de la carretera, puede construir el tipo correcto de automóvil.

Para decirlo de otra manera, Maven es un marco mientras que Ant es una caja de herramientas. Si está contento con trabajar dentro de los límites del marco, entonces Maven funcionará bien. El problema para mí era que seguía tropezando con los límites del marco y no me dejaba salir.

Verbosidad XML

Tobrien es un tipo que sabe mucho sobre Maven y creo que proporcionó una comparación muy buena y honesta de los dos productos. Comparó un Maven pom.xml simple con un simple archivo de compilación Ant e hizo mención de cómo los proyectos Maven pueden volverse más complejos. Creo que vale la pena echar un vistazo a una comparación de un par de archivos que es más probable que veas en un proyecto simple del mundo real. Los archivos a continuación representan un solo módulo en una compilación de varios módulos.

Primero, el archivo Maven:

<project 
    xmlns="http://maven.apache.org/POM/4.0.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-4_0_0.xsd">

    <parent>
        <groupId>com.mycompany</groupId>
        <artifactId>app-parent</artifactId>
        <version>1.0</version>
    </parent>

    <modelVersion>4.0.0</modelVersion>
    <artifactId>persist</artifactId>
    <name>Persistence Layer</name>

    <dependencies>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>common</artifactId>
            <scope>compile</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>com.mycompany</groupId>
            <artifactId>domain</artifactId>
            <scope>provided</scope>
            <version>${project.version}</version>
        </dependency>

        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate</artifactId>
            <version>${hibernate.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>commons-lang</groupId>
            <artifactId>commons-lang</artifactId>
            <version>${commons-lang.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring</artifactId>
            <version>${spring.version}</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.dbunit</groupId>
            <artifactId>dbunit</artifactId>
            <version>2.2.3</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>${testng.version}</version>
            <scope>test</scope>
            <classifier>jdk15</classifier>
        </dependency>

        <dependency>
            <groupId>commons-dbcp</groupId>
            <artifactId>commons-dbcp</artifactId>
            <version>${commons-dbcp.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>com.oracle</groupId>
            <artifactId>ojdbc</artifactId>
            <version>${oracle-jdbc.version}</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>${easymock.version}</version>
            <scope>test</scope>
        </dependency>

    </dependencies>

</project>

Y el archivo Ant equivalente:

<project name="persist" >

    <import file="../build/common-build.xml" />


    <path id="compile.classpath.main">
        <pathelement location="${common.jar}" />
        <pathelement location="${domain.jar}" />
        <pathelement location="${hibernate.jar}" />
        <pathelement location="${commons-lang.jar}" />
        <pathelement location="${spring.jar}" />
    </path>


    <path id="compile.classpath.test">
        <pathelement location="${classes.dir.main}" />
        <pathelement location="${testng.jar}" />
        <pathelement location="${dbunit.jar}" />
        <pathelement location="${easymock.jar}" />
        <pathelement location="${commons-dbcp.jar}" />
        <pathelement location="${oracle-jdbc.jar}" />
        <path refid="compile.classpath.main" />
    </path>


    <path id="runtime.classpath.test">
        <pathelement location="${classes.dir.test}" />
        <path refid="compile.classpath.test" />
    </path>


</project>

tobrien usó su ejemplo para mostrar que Maven tiene convenciones incorporadas, pero eso no significa necesariamente que termine escribiendo menos XML. He encontrado lo contrario para ser verdad. El pom.xml es 3 veces más largo que el build.xml y eso es sin apartarse de las convenciones. De hecho, mi ejemplo de Maven se muestra sin 54 líneas adicionales que fueron necesarias para configurar complementos. Ese pom.xml es para un proyecto simple. El XML realmente comienza a crecer significativamente cuando comienza a agregar requisitos adicionales, lo que no está fuera de lo común para muchos proyectos.

Pero tienes que decirle a Ant qué hacer

Mi ejemplo anterior de Ant no está completo, por supuesto. Todavía tenemos que definir los objetivos utilizados para limpiar, compilar, probar, etc. Estos se definen en un archivo de compilación común que es importado por todos los módulos en el proyecto de módulos múltiples. Lo que me lleva al punto sobre cómo todo esto debe escribirse explícitamente en Ant, mientras que es declarativo en Maven.

Es cierto, me ahorraría tiempo si no tuviera que escribir explícitamente estos objetivos Ant. Pero cuanto tiempo? El archivo de compilación común que uso ahora es uno que escribí hace 5 años con solo pequeños ajustes desde entonces. Después de mi experimento de 2 años con Maven, saqué el viejo archivo de compilación Ant del armario, lo desempolvé y lo puse de nuevo a trabajar. Para mí, el costo de tener que decirle explícitamente a Ant qué hacer ha sumado menos de una semana en un período de 5 años.

Complejidad

La siguiente gran diferencia que me gustaría mencionar es la complejidad y el efecto real que tiene. Maven fue construido con la intención de reducir la carga de trabajo de los desarrolladores encargados de crear y administrar procesos de construcción. Para hacer esto tiene que ser complejo. Lamentablemente, esa complejidad tiende a negar su objetivo previsto.

En comparación con Ant, el chico de construcción en un proyecto Maven pasará más tiempo:

• Lectura de documentación: hay mucha más documentación sobre Maven, porque hay mucho más que necesita aprender.
• Educar a los miembros del equipo: les resulta más fácil preguntar a alguien que conoce que tratar de encontrar respuestas por sí mismos.
• Solución de problemas de la compilación: Maven es menos confiable que Ant, especialmente los complementos no principales. Además, las compilaciones de Maven no son repetibles. Si depende de una versión SNAPSHOT de un complemento, lo cual es muy probable, su compilación puede romperse sin que haya cambiado nada.
• Escribir complementos de Maven: los complementos generalmente se escriben con una tarea específica en mente, por ejemplo, crear un paquete de inicio web, lo que hace que sea más difícil reutilizarlos para otras tareas o combinarlos para lograr un objetivo. Por lo tanto, es posible que tenga que escribir uno de los suyos para solucionar las brechas en el conjunto de complementos existente.

A diferencia de:

• La documentación de Ant es concisa, completa y todo en un solo lugar.
• Ant es simple. Un nuevo desarrollador que intenta aprender Ant solo necesita comprender algunos conceptos simples (objetivos, tareas, dependencias, propiedades) para poder descubrir el resto de lo que necesita saber.
• Ant es confiable. No ha habido muchos lanzamientos de Ant en los últimos años porque ya funciona.
• Las compilaciones de Ant son repetibles porque generalmente se crean sin dependencias externas, como repositorios en línea, complementos de terceros experimentales, etc.
• Ant es integral. Debido a que es una caja de herramientas, puede combinar las herramientas para realizar casi cualquier tarea que desee. Si alguna vez necesita escribir su propia tarea personalizada, es muy simple de hacer.

Familiaridad

Otra diferencia es la de familiaridad. Los nuevos desarrolladores siempre requieren tiempo para ponerse al día. La familiaridad con los productos existentes ayuda en ese sentido y los partidarios de Maven afirman con razón que esto es un beneficio de Maven. Por supuesto, la flexibilidad de Ant significa que puede crear las convenciones que desee. Entonces, la convención que uso es poner mis archivos fuente en un nombre de directorio src / main / java. Mis clases compiladas van a un directorio llamado target / classes. Suena familiar, ¿no?

Me gusta la estructura de directorios utilizada por Maven. Creo que tiene sentido. También su ciclo de vida de construcción. Así que uso las mismas convenciones en mis compilaciones Ant. No solo porque tiene sentido, sino porque será familiar para cualquiera que haya usado Maven antes.

Ant es principalmente una herramienta de construcción.

Maven es una herramienta de gestión de proyectos y dependencias (que, por supuesto, también construye su proyecto).

Ant + Ivy es una combinación bastante buena si quieres evitar a Maven.

Solo para enumerar algunas diferencias más:

• Ant no tiene convenciones formales. Tienes que decirle a Ant exactamente dónde encontrar la fuente, dónde colocar las salidas, etc.
• Ant es procesal. Tienes que decirle a Ant exactamente qué hacer; dígale que compile, copie, luego comprima, etc.
• Ant no tiene un ciclo de vida.
• Maven usa convenciones. Sabe dónde está su código fuente automáticamente, siempre y cuando siga estas convenciones. No necesitas decirle a Maven dónde está.
• Maven es declarativo; Todo lo que tiene que hacer es crear un archivo pom.xml y colocar su fuente en el directorio predeterminado. Maven se encargará del resto.
• Maven tiene un ciclo de vida. Simplemente llame a mvn install y se ejecutará una serie de pasos de secuencia.
• Maven tiene inteligencia sobre las tareas comunes del proyecto. Para ejecutar pruebas, simplemente ejecute mvn test , siempre que los archivos estén en la ubicación predeterminada. En Ant, primero tendría que crear el archivo JUnit JAR, luego crear una ruta de clase que incluya el JUnit JAR, luego decirle a Ant dónde debe buscar el código fuente de la prueba, escribir un objetivo que compile la fuente de la prueba y finalmente ejecutar las pruebas unitarias con JUnit.

Actualizar:

Esto vino de Maven: la guía definitiva . Lo siento, olvidé por completo citarlo.

Maven o Ant? es una pregunta muy similar a esta, que debería ayudarlo a responder sus preguntas.

¿Qué es maven? en el sitio oficial.

editar: Para un proyecto nuevo / greenfield, recomendaría usar Maven: la "convención sobre la configuración" le ahorrará una buena cantidad de tiempo al escribir y configurar scripts de compilación y despliegue. Cuando usa Ant, el script de compilación tiende a crecer con el tiempo en longitud y complejidad. Para proyectos existentes, puede ser difícil calzar su configuración / diseño en el sistema Maven.

Maven actúa como una herramienta de administración de dependencias, se puede usar para recuperar frascos de un repositorio central o de un repositorio que configuró, y como una herramienta de compilación declarativa. La diferencia entre una herramienta de compilación "declarativa" y una más tradicional como Ant o Make es que configura lo que debe hacerse, no cómo se hace. Por ejemplo, puede decir en un script de Maven que un proyecto debe empaquetarse como un archivo WAR, y Maven sabe cómo manejarlo.

Maven se basa en convenciones sobre cómo se presentan los directorios del proyecto para lograr su "declaratividad". Por ejemplo, tiene una convención sobre dónde colocar su código principal, dónde colocar su web.xml, sus pruebas unitarias, etc., pero también brinda la posibilidad de cambiarlos si es necesario.

También debe tener en cuenta que hay un complemento para ejecutar comandos ant desde Maven:

http://maven.apache.org/plugins/maven-ant-plugin/

Además, los arquetipos de Maven hacen que comenzar un proyecto sea realmente rápido. Por ejemplo, hay un arquetipo de Wicket, que proporciona un comando maven que ejecuta para obtener un proyecto de tipo hello world completo y listo para ejecutarse.

https://wicket.apache.org/start/quickstart.html

Puedo llevar a una persona que nunca ha visto a Ant (sus build.xmlmensajes están razonablemente bien escritos) y pueden entender lo que está sucediendo. Puedo tomar a esa misma persona y mostrarles un Maven POM y no tendrán idea de lo que está sucediendo.

En una organización de ingeniería que es enorme, la gente escribe sobre archivos Ant que se vuelven grandes e inmanejables. He escrito esos tipos y limpio scripts Ant. Realmente es comprender por adelantado lo que debe hacer en el futuro y diseñar un conjunto de plantillas que puedan responder al cambio y escalar en un período de más de 3 años.

A menos que tenga un proyecto simple, aprender las convenciones de Maven y la forma de Maven de hacer las cosas es bastante trabajo.

Al final del día, no puede considerar el inicio del proyecto con Ant o Maven como un factor: es realmente el costo total de propiedad. Lo que se necesita para que la organización mantenga y extienda su sistema de construcción durante algunos años es uno de los principales factores que deben considerarse.

Los aspectos más importantes de un sistema de compilación son la administración de dependencias y la flexibilidad para expresar la receta de compilación. Debe ser algo intuitivo cuando se hace bien.

Diría que depende del tamaño de su proyecto ... Personalmente, usaría Maven para proyectos simples que requieren compilación, empaquetado y despliegue sencillos. Tan pronto como necesite hacer algunas cosas más complicadas (muchas dependencias, crear archivos de mapeo ...), cambiaría a Ant ...

Maven también alberga un gran repositorio de proyectos de código abierto comúnmente utilizados. Durante la compilación, Maven puede descargar estas dependencias por usted (así como sus dependencias de dependencias :)) para que esta parte de la construcción de un proyecto sea un poco más manejable.