Diferencias entre Ant y Maven

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

What is Maven? en el sitio oficial.

Editar: Para un proyecto nuevo/nuevo, recomiendo usar Maven: "convención sobre configuración" le ahorrará un tiempo decente en la escritura y la configuración de scripts de compilación y despliegue. Cuando utilizas hormiga, la secuencia de comandos de construcció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.

Answer 4

Ant es principalmente una herramienta de compilación.

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

Ant + Ivy es una muy buena combinación si desea evitar Maven.

Answer 5

por mencionar algunos más diferencias:

• hormiga no tiene convenciones formales. Tienes que decirle a Ant exactamente dónde encontrar la fuente, dónde colocar las salidas, etc.
• Ant es de procedimiento. 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 las convenciones. Sabe dónde está su código fuente automáticamente, siempre y cuando siga estas convenciones. No es necesario que le digas 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 al mvn install y se ejecuta una serie de pasos de secuencia.
• Maven tiene inteligencia sobre las tareas comunes del proyecto. Para ejecutar pruebas, ejecute simple mvn test, siempre que los archivos estén en la ubicación predeterminada. En Ant, primero deberías JUnit JAR file is, luego crear una classpath que incluya JUnit JAR, luego decirle a Ant dónde debería buscar el código fuente de prueba, escribir un objetivo que compila la fuente de prueba y luego ejecutar las pruebas unitarias con JUnit.

Actualización:

Esto vino de Maven: The Definitive Guide. Lo siento, me olvidé de citarlo.

Answer 6

Maven actúa como una herramienta de administración de dependencias, se puede usar para recuperar archivos jar desde un repositorio central o desde un repositorio que haya configurado, y como una herramienta de creación declarativa. La diferencia entre una herramienta de compilación "declarativa" y una herramienta de compilación más "tradicional" es configurar lo que debe hacerse, no cómo se hace. Por ejemplo, puede decir en un script maven que un proyecto debe estar empaquetado como un archivo WAR, y maven sabe cómo manejarlo.

Maven confía en las convenciones sobre cómo se diseñan los directorios de proyectos para lograr su "declarativa". Por ejemplo, tiene una convención para dónde colocar su código principal, dónde colocar su web.xml, las pruebas de su unidad, etc., pero también le permite cambiarlas si es necesario.

También debe tener en cuenta que hay un plugin para ejecutar comandos de hormigas dentro de Maven:

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

Además, los arquetipos de Maven hacer conseguir comenzó con un proyecto muy rápido. Por ejemplo, hay un arquetipo de Wicket, que proporciona un comando maven que ejecuta para obtener un proyecto tipo hello world completo, listo para ejecutar.

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

Answer 7

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

una simple comparación

Sólo estoy mostrando esto para ilustrar la idea de que, en el nivel más básico, Maven ha incorporado en las convenciones. Esto es un simple fichero de construcción Ant:

<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 Hormiga, se puede ver cómo se tiene que decirle a Ant exactamente qué hacer. Existe un objetivo de compilación que incluye la tarea javac que compila el origen en el directorio src/main/java en el directorio target/classes. Tienes que decirle a Ant exactamente dónde está tu fuente, dónde quieres que se guarde el bytecode resultante y cómo empacar todo esto en un archivo JAR. Si bien hay algunos desarrollos recientes que ayudan a Ant a ser 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 a partir de una fuente Java, todo lo que necesita hacer es crear un simple pom.xml, colocar su código fuente en $ {basedir}/src/main/java y luego ejecutar mvn install desde la línea de comando . 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 necesita en su pom.xml. Al ejecutar mvn install desde la línea de comandos, se procesarán los recursos, se compilará el origen, se ejecutarán pruebas unitarias, se creará un JAR y se instalará el JAR en un repositorio local para su reutilización en otros proyectos. Sin modificación, puede ejecutar el sitio mvn y luego encontrar un archivo index.html en el destino/sitio 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. 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 más grande de los proyectos puede ver colecciones de POM Maven muy complejos que contienen una gran cantidad de personalizaciones de plugins y declaraciones de dependencia. Pero, incluso cuando los archivos POM de su proyecto se vuelven más sustanciales, contienen un tipo de información completamente diferente del archivo de compilación de un proyecto de tamaño similar que usa 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: "Esto es proyecto", "La fuente está en src/main/java", "Ejecute javac contra este directorio", "Ponga los resultados en target/classses", "Cree un JAR desde ....", etc. Cuando Ant tuvo 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.

-alto nivel de comparación

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

• no tiene convenciones formales como una estructura de directorio de proyecto común, tiene que 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 han sido codificadas en el producto.
• es procedural, tienes que decirle a Ant exactamente qué hacer y cuándo hacerlo. Tuviste que decirlo para compilar, luego copiar, luego comprimir.
• no tiene un ciclo de vida, debe definir objetivos y dependencias de objetivos. Debes adjuntar manualmente una secuencia de tareas a cada objetivo.

Dónde Maven ...

• tiene convenciones, ya sabía donde su código fuente se debía a que ha seguido la convención. Puso el bytecode en target/classes, y produjo un archivo JAR en el objetivo.
• es declarativo. Todo lo que tenía que hacer era crear un archivo pom.xml y poner su fuente en el directorio predeterminado. Maven se encargó del resto.
• tiene un ciclo de vida que invocó cuando ejecutó 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é pasa con Ivy?

Bien, entonces alguien como Steve Loughran va a leer esa comparación y llamar a foul. É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 las versiones más recientes de Ant. Esto es verdad. Si tienes un grupo de personas inteligentes que usan Ant + antlibs + Ivy, terminarás con una construcció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 astuto. Una vez dicho esto, creo que terminarás perdiendo una cantidad de complementos valiosos como el plugin Jetty y que terminarás haciendo un montón de trabajo que no necesitas hacer a lo largo del tiempo.

más importante que Maven contra Ant

1. es que se utiliza un administrador de repositorio para realizar un seguimiento de los artefactos de software. Sugeriría downloading Nexus. Puede usar Nexus para proxy repositorios remotos y proporcionar un lugar para que su equipo implemente artefactos internos.
2. Tiene la modularización adecuada de los componentes de software. Un gran componente monolítico rara vez aumenta con el tiempo. A medida que su proyecto se desarrolla, querrá tener el concepto de módulos y submódulos. Maven se presta muy bien a este enfoque.
3. Adoptas algunas convenciones para tu compilación. Incluso si usa Ant, debe esforzarse por adoptar algún tipo de convención que sea coherente con otros proyectos. Cuando un proyecto utiliza Maven, significa que cualquiera que esté familiarizado con Maven puede recoger la compilación y comenzar a ejecutarla sin tener que jugar con la configuración solo para descubrir cómo hacer para compilarla.

Answer 8

puedo llevar a una persona que nunca ha visto Hormiga - build.xml sus s están razonablemente bien escrito - y ellos pueden entender lo que está pasando. Puedo tomar esa misma persona y mostrarles un Maven POM y no tendrán idea de lo que está pasando.

En una organización de ingeniería que es enorme, las personas escriben sobre archivos Ant que se vuelven grandes e inmanejables. He escrito esos tipos de scripts Clean Ant y. Realmente entiende por adelantado lo que debe hacer en el futuro y diseña un conjunto de plantillas que pueden responder al cambio y la escala en un período de más de 3 años.

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

Al final del día no se puede considerar el inicio del proyecto con Ant o Maven un factor: es realmente el costo total de propiedad. Lo que se necesita para que la organización mantenga y amplíe su sistema de compilación en unos pocos años es uno de los principales factores que deben tenerse en cuenta.

Los aspectos más importantes de un sistema de compilación son la gestión de la dependencia y la flexibilidad en la expresión de la receta de compilación. Debe ser algo intuitivo cuando se hace bien.

Answer 9

Maven es un marco, Ant es una caja de herramientas

Maven es un coche pre-construidos por carretera, mientras que la hormiga es un conjunto de piezas de automóviles. Con Ant tienes que construir tu propio auto, pero al menos si necesitas conducir fuera de la carretera puedes construir el tipo correcto de auto.

Para decirlo de otra manera, Maven es un marco mientras que Ant es una caja de herramientas. Si está satisfecho trabajando dentro de los límites del marco, Maven lo hará bien. El problema para mí fue que seguí chocando con los límites del marco y no me dejaba salir.

Verbosidad XML

tobrien es un tipo que sabe mucho acerca de Maven y creo que proporcionó una comparación muy buena, honesta de los dos productos. Comparó un simple Maven pom.xml con un simple archivo Ant build y mencionó cómo los proyectos Maven pueden volverse más complejos. Creo que vale la pena echarle 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 siguientes archivos representan un solo módulo en una compilación de varios módulos.

En primer lugar, 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 ha incorporado en las convenciones, pero eso no significa necesariamente que termines escribiendo menos XML. He encontrado que lo opuesto es verdad. El pom.xml es 3 veces más largo que el build.xml y eso sin desviarse de las convenciones. De hecho, mi ejemplo de Maven se muestra sin un adicional de 54 líneas que se requieren para configurar los 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 es extraordinario para muchos proyectos.

pero hay que decirle qué hacer Ant

Mi ejemplo Hormiga anterior no es completa, 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 varios módulos. Lo que me lleva al punto acerca de cómo todo esto debe escribirse explícitamente en Ant, mientras que es declarativo en Maven.

Es verdad, 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 algunos pequeños ajustes desde entonces. Después de mi experimento de 2 años con Maven, saqué el viejo archivo de compilación de Ant del armario, lo desempolvé y lo puse en funcionamiento nuevamente. Para mí, el costo de tener que decirle explícitamente a Ant qué hacer se ha sumado a menos de una semana en un período de 5 años.

Complejidad

La diferencia principal siguiente que me gustaría mencionar es el de la complejidad y el efecto en el mundo real que tiene. Maven se creó con la intención de reducir la carga de trabajo de los desarrolladores encargados de crear y administrar procesos de compilación. Para hacer esto, tiene que ser complejo. Desafortunadamente, la complejidad tiende a negar su objetivo previsto.

Cuando se compara con Ant, el tipo de construcción en un proyecto Maven pasar más tiempo:

• documentación de lectura: Hay mucha más documentación sobre Maven, porque hay muchas más cosas que necesitan aprender.
• Educar a los miembros del equipo: les resulta más fácil preguntar a alguien que sabe en lugar de tratar de encontrar las respuestas.
• Solución de problemas de la compilación: Maven es menos confiable que Ant, especialmente los complementos no esenciales. Además, las compilaciones de Maven no son repetibles. Si dependes de una versión SNAPSHOT de un complemento, lo cual es muy probable, tu compilación puede romperse sin que hayas cambiado nada.
• Escritura de complementos de Maven: los complementos generalmente se escriben con una tarea específica en mente, p. crea un paquete webstart, 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 resolver brechas en el conjunto de complementos existente.

Por el contrario:

• documentación Ant es concisa, completa y 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 muchas versiones de Ant en los últimos años porque ya funciona.
• Las compilaciones Ant se pueden repetir porque generalmente se crean sin dependencias externas, como repositorios en línea, complementos experimentales de terceros, etc.
• Ant es completo. 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 que la 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 compilación. Así que uso las mismas convenciones en mis compilaciones Ant. No solo porque tenga sentido, sino porque será familiar para cualquiera que haya usado antes a Maven.