Maven o Ivy para la Gestión de Dependencias de Ant?

Ant + Ivy == Un campamento, donde la gente usa las instalaciones según sea necesario.
Maven = = Un resort, donde usted confía en alguien más para proporcionar servicios.

Maven es más fácil para un equipo que carece de experiencia de compilación/integración, pero cuando el equipo necesita divergir de los estándares Maven, se encontrarán alcanzando groovy, gradle y la falta de documentación sólida se volverá frustrante.

Ant + Ivy tardará más en iniciar un proyecto, pero si el equipo tiene compilación / integración experiencia pueden adaptar el sistema de compilación a su forma de desarrollar y publicar código.

En ingeniería... empresas de tecnología Siempre presiono por la solución de camping frente al resort.

Sin embargo, es increíble que tanto Ant como Maven elijan XML como su idioma para expresar recetas de construcción. La comunidad Java está atascada en ese XML...

Ivy+Ant es mucho, mucho más flexible. Ivy hace la gestión de dependencias, punto, y lo hace muy bien, mejor que Maven. Y con Ant puedes armar cualquier sistema de construcción que quieras.

Maven intenta controlar todo - el "ciclo de vida" (compile, test, package, etc.).), donde los archivos deben vivir, y así sucesivamente. Diviértete personalizando plugins y similares si no te gusta el "Maven way".

Maven es la respuesta a una pregunta que nadie hizo. Escribir una Hormiga el script no es difícil, y Ivy te da una mejor gestión de dependencias que Maven. Estoy confundido por algunos de los comentarios anteriores que indican que no podían conseguir Ivy trabajando. Ivy es un poco más simple que Maven para ponerse en marcha.

El Framework Spring utiliza Ivy en su proceso de construcción. Creo que eso puede ser visto como un voto de confianza para Ivy.

Creo que esta entrada de blog cubre exactamente lo que la OP está buscando:

Por qué debería usar las tareas Maven Ant en lugar de Maven o Ivy

Si su objetivo a largo plazo es migrar a usar Maven para administrar todo el proceso de compilación (lo que uno podría tener la intención de hacer para nuevos proyectos de nueva creación), entonces recomiendo encarecidamente usar Maven pom.archivos xml para gestionar dependencias en nombre de Ant build.archivos xml. El resultado final es que tanto sus proyectos nuevos como sus proyectos heredados están utilizando el mismo mecanismo para administrar dependencias. Y resulta que Maven realmente hace un mejor trabajo de gestión de dependencias para Ant build.XML archivos que Ivy.

Antes de adoptar Maven como nuestra herramienta de construcción insignia, tuve un intento de desarrollador de usar Ivy en combinación con la construcción Ant existente.archivos xml. Esta fue la experiencia más frustrante que muy pronto nos llevó a rechazar a Ivy. Seguimos adelante con la adopción de Maven. Nuestros proyectos greenfield comenzaron a construirse con el enfoque de stock Maven, etc.

Sin embargo, volví a los proyectos heredados de Ant y comencé a usar la tarea Maven Ant para definir definiciones de classpath (y ocasionalmente otras definiciones de propiedad Ant se extraen del pom.XML). Esto resultó ser una experiencia superlativa. La construcción de Hormigas existente.los archivos xml solo necesitan ser modificados ligeramente para usar la integración Maven ant para definir cualquier classpath que estuviera en uso en la compilación.archivo xml. Todas las dependencias requeridas por el proyecto se definieron en un pom adjunto.archivo xml que es procesado por Maven a través de la tarea Ant incorporada en la compilación.archivos xml.

Los alcances Maven se pueden utilizar para fine tune classpath definitions such that one suitable for compiling, or running unit test, or for packaging, et al, can be established. Además, casi cualquier elemento de algo definido en el pom.el archivo xml se puede referenciar como una propiedad Ant dentro de la compilación.archivo xml.

Realmente con la tarea Hormiga para Maven no hay razón viable para que Ivy siquiera exista.

Comparar a Maven con ivy/ant es comparar un teléfono inteligente con telegrafía.

Si desea aprovechar un efecto duradero real en su infraestructura de construcción, es mejor usar Maven porque anticipa y abstrae todos los procesos y tareas con los que se enfrenta cada proyecto de software u otro proyecto similar al software. Participé en muchos proyectos y si sus proyectos se vuelven más complejos y más diversos y más heterogéneos, elogiará aún más la simplicidad de un proyecto Maven configuración. De hecho, se volverá complejo pero no complicado en comparación con los proyectos impulsados por ivy/ant.

La principal ventaja de Maven es " convención sobre configuración "(http://en.wikipedia.org/wiki/Convention_over_configuration) un paradigma muy importante. En resumen, esto significa que no necesita saber/configurar cosas que son obvias/triviales/comunes. Aunque Maven y todos sus plugins vienen con muchos ajustes predeterminados, siempre tienes la opción de configurar tus proyectos para tus necesidades especiales. Con Maven, por un lado puedes configurar un proyecto muy fácil y rápidamente; por otro lado, puedes personalizar un proyecto en crecimiento hasta tus necesidades con el mínimo esfuerzo. Si ha entendido los conceptos clave detrás de Maven, aprovechará cada proyecto y también los proyectos que no son proyectos de desarrollo de software típicos también.

En el pasado, escribí muchos guiones de hormigas y con el próximo Maven comencé a odiar a ant. Una desventaja es que siempre copia scripts y repítete, desarrolla tareas de hormigas que no repitan tareas que no repiten tareas que no repiten... Y la principal desventaja es que el cultivo de scripts ant tienden a obtener tanto, especialmente si una docena de hormiga frikis quieren chulo cada uno de los otros scripts ant.

Muchos entusiastas de las hormigas sufren al obtener el control general sobre cosas triviales como copiar artefactos e imprimir buildmessages. Pero debido a que el concepto clave de Maven es ocultar estas cosas triviales la leyenda guardará para siempre vivo que Maven restringe las necesidades de personalización. Pero no te preocupes, eso es una leyenda! Y así finalmente entiendes mi declaración inicial: no te molestes con cosas triviales que ya están resueltas.

Tal vez ivy/ant es una opción para proyectos simples, pero para proyectos complejos en crecimiento necesita simplicidad y convenciones. De lo contrario, se verá abrumado con más y más problemas de mantenimiento. Especialmente si usted tiene muchos proyectos dependientes, tecnologías y piezas heterogéneas del producto en un proyecto global no tiene tiempo ni dinero para desarrollar y probar scripts ant o resolver problemas de dependencia.

Otro consejo debe ser mencionado: Ant ofrece la integración de Maven. Esta integración se usa a menudo para probar y jugar con maven en proyectos que han crecido con ant. Evite este enfoque estúpido porque genera más problemas. En su lugar, quédate con ant y su dolor o migra completamente a maven.

Si tiene dudas sobre los costos de migración, le sugiero que usa la forma contraria de integrar esos mundos diferentes con el Maven-Ant-Plugin. Con este plugin estándar se puede ejecutar cada ant-script sin ningún esfuerzo. Claro que es una solución heredada por un tiempo, pero le da tanto tiempo que necesita para entender mega-líneas de monstruosos scripts ant distorsionados sin comentarios de su predecesor.

Y ahora elogiará la siguiente ventaja de maven: Necesita muy menos documentación de su configuración, porque la documentación es parte de cada maven-plugin que desea utilizar.

Sé que una ventaja de Ivy es que puede usar diferentes tipos de repositorios. Maven es típicamente muy rígido en el formato del repositorio que usará. Es todo lo que sé.

Acabo de pasar 2 días leyendo la documentación de Ivy y tengo que decir, USA MAVEN si tienes alguna opción. Ivy es una completa y absoluta basura por lo que puedo decir. Acabo de perder 2 días tratando de incorporarlo en mi estructura y estoy cortando mis pérdidas ahora. ¿Por qué?

• Ivy es un intento a medias de gestión de dependencias
• La documentación de Ivy es una broma total
• Ivy ejemplos y tutorial son inútiles

Tan pronto como introduje 'configuraciones' (leer como maven perfiles), Ivy comenzó a ir bezerk descargar todo tipo de basura que no necesito a continuación, fallando. La documentación de Ivy es una broma. La documentación de Maven en comparación se lee como un sueño. Si quieres un ejemplo de lo impenetrable y mal escrita que está la documentación de Ivy, echa un vistazo a la página de referencia para configuraciones. Estos son una parte esencial de cualquier construcción, pero en Ivy parecen ser un mal diseñado después del pensamiento.