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.