¿Ant todavía está en la "corriente principal" para las compilaciones de Java?

14

Hemos estado reemplazando lentamente los archivos de comandos por lotes (Windows .bat) que simplemente sacudían las clases compiladas en el IDE de los desarrolladores, con compilaciones Ant más completas (es decir, obtener de CVS, compilación limpia, jar, archivo, correo electrónico, etc.)

He pasado mucho tiempo aprendiendo (y depurando problemas) con Ant, así que me siento más cómodo usándolo para estas tareas. Pero me pregunto si Ant todavía tiene un uso tan amplio como cuando comencé a aprender, o si "el mundo ha avanzado" hacia algo más nuevo (y tal vez más elegante). (Comencé a ver más cosas de compilación de Maven distribuidas, que nunca he usado, por ejemplo).

La importancia práctica de esta pregunta es si presiono a los nuevos desarrolladores para que aprendan Ant o si deberían aprender algo más para las compilaciones.

Nunca estoy demasiado al tanto de las tendencias, por lo que sería genial saber de otros desarrolladores de Java qué creen que es la mejor herramienta de compilación y qué creen que deberían estar aprendiendo los nuevos desarrolladores.

— Sam Goldberg
fuente

¡Lea todas las respuestas a continuación y todas fueron geniales! Gracias por la información sobre las mejoras que ofrece Maven sobre Ant. Estaré investigando a Maven.

— Sam Goldberg

Son muy pocos los proyectos que son lo suficientemente simples como para no requerir toneladas de secuencias de comandos para hormiga. Maven maneja muchas de estas cosas de manera estándar.

Ant es básicamente un script de shell en XML (y usa comandos Ant en lugar de comandos shell).

— user253751

Ant es una increíble pérdida de tiempo. Incluso cuando Maven era terrible, era una elección más inteligente. Ant no tiene forma de integrarse en un IDE y los proyectos de Java son una gran cantidad de archivos: pasas el 30% de tu tiempo saltando de un archivo a otro.

— bryan hunt

@bryanhunt: terminamos usando Maven para todos los proyectos nuevos. Sin embargo, no he encontrado una buena manera para que Maven cree un paquete de implementación para aplicaciones Java. (Está bien para copiar dependencias, cargar jar.) La mayoría de las publicaciones que leo que responden cómo hacerlo, por ejemplo, para usar el complemento Ant. Entonces descubro que estoy usando Ant para preparar el resultado final de Maven. Y parece mucho más fácil hacerlo en Ant que usar el complemento Maven Assembly.

— Sam Goldberg

23

Estoy de acuerdo con otros aquí en que Maven parece haberse hecho cargo de los proyectos más importantes que he visto.

Si bien Ant es muy flexible, el archivo de compilación no está estandarizado, por lo que cuando se muda a un nuevo proyecto o empresa, los objetivos se nombran de manera diferente, el archivo está estructurado de manera diferente, las dependencias entre objetivos pueden o no establecerse, etc.

Con Maven, también obtienes el beneficio de no tener que cargar dependencias binarias (estoy hablando de jarras) en tu sistema SCM. Muchas otras excelentes herramientas de Java saben cómo leer un archivo POM de Maven (el beneficio de la estandarización), por lo que herramientas como IDE pueden configurar un proyecto de Maven muy rápidamente, y herramientas de compilación como Jenkins pueden ejecutar fácilmente compilaciones de Maven.

— RonU
fuente

13

También debo agregar que usar Maven hace que nuestros proyectos sean independientes de IDE, y si alguna vez has estado en una tienda que tuvo guerras de IDE, ¡puedes apreciar eliminar esta batalla religiosa!

— RonU

11

He estado trabajando con Ant y con Maven. En mi experiencia, Maven tiene una ventaja muy fuerte sobre Ant.

Todos los proyectos que he visto en los últimos 2 o 3 años parecen estar usando Maven. Hace unos 3 años, esto me hizo preguntarme porque las versiones de Maven utilizadas en ese momento (2.0.algo) parecían ser poco confiables y con errores. Sin embargo, en algún momento (2.1 o 2.2 no recuerdo) Maven se volvió confiable y después de pasar un tiempo con él, he cambiado de opinión a opuesto. Ahora, preferiría estar sorprendido de ver a alguien que prefiere a las hormigas sobre los expertos.

En una nota menos positiva sobre Maven, mi experiencia con su documentación no fue tan buena hasta ahora. Creo que he visto un producto con documentación peor que la de Maven, pero no recuerdo cuál (alguna antigua biblioteca CSV iirc).

— mosquito
fuente

2

No sé, encontré la referencia de Maven bastante decente. No es perfecto, y hay rincones oscuros indocumentados, pero en mi humilde opinión, es significativamente mejor que el promedio.

— Péter Török

@ PéterTörök derecho Maven Reference es mi primer auxilio también. De alguna manera, aunque la mayoría de las cosas que me preocupa terminan en estos rincones oscuros indocumentados . Para ser precisos, encuentro estos rincones más "oscuros" que "indocumentados". Quiero decir que siento que el conocimiento está ahí, pero no puedo descifrarlo. No sé, tal vez soy desafortunado. O tal vez tonto. O tal vez chicos Maven simplemente carecen de un escritor de tecnología decente en su banda

— mosquito

1

¿Por qué, alguna vez has visto un proyecto de código abierto que tuviera un escritor técnico decente? ;-)

— Péter Török

@ PéterTörök tan cierto! :) El lujo de los proyectos populares de OSS es que hay muchos tipos expertos que "reemplazan" al escritor de documentos. Para mí, ese fue el caso con Maven: siempre ha habido algún gurú a quien podría preguntar sobre cosas difíciles

— mosquito el

3

Hemos estado usando Maven por varios años. Admite secuencias de comandos Ant (al igual que Ant admite BeanShell), por lo que su conocimiento Ant aún puede ser útil. Maven es mucho más potente, pero tiene algunos requisitos de infraestructura adicionales (querrá un servidor Artifactory o Nexus para alojar sus compilaciones si comparte componentes entre múltiples proyectos). También es bastante diferente de Ant, por lo que no puede aprovechar gran parte de su conocimiento existente.

— TMN
fuente

1

Creo que Ant está sola en el agua; tener que especificar todas sus dependencias classpath manualmente (dependiendo de su configuración) es demasiado manual y propenso a errores. Si Ant se usa junto con una herramienta de administración de dependencias, como Ivy, entonces retiene su poder y elimina la necesidad de administrar manualmente sus dependencias.

El otro problema con Ant en comparación con Maven es la falta de estandarización, que se ha mencionado en otras respuestas. Al pasar de un proyecto a otro o de un trabajo a otro, una de las cosas más molestas que encuentro es tener que aprender el nuevo estándar para diferentes archivos Ant. El objetivo de la convención sobre la configuración de Maven significa que dos proyectos diferentes tendrán una estructura muy similar, haciendo que la transición entre ellos sea mucho más fácil que con Ant.

En cuanto a si Ant sigue siendo convencional o no, dependerá del entorno de desarrollo en el que esté trabajando. Si el proyecto se encuentra en una pequeña empresa o en una nueva empresa, me imagino que Maven sería la elección natural y se puede tomar el tiempo invertir en la infraestructura, como un artefacto. Sin embargo, las grandes empresas habrán invertido muchos años y mucho dinero en su infraestructura Ant (configuraciones, archivos de compilación global, etc.), lo que significa que estarán menos interesadas en alejarse de una tecnología en la que han invertido tanto dinero.

— Ricardo
fuente

0

Maven ha estado en aumento durante muchos años, y ahora necesito aprenderlo. Las cosas siempre cambiarán, y saber que Ant está perdiendo su posición no es algo malo.

Es posible que Maven solo sea el mejor por poco tiempo, pero si facilita nuestro trabajo, entonces vale la pena invertir el tiempo para aprender.

— Jon Shanks
fuente