Apache Ant: Significado Empresarial y su Rol en el Desarrollo de Software

Apache Ant, cuyo nombre es un acrónimo de "Another Neat Tool" (Otra Herramienta Genial), es una herramienta de automatización y desarrollo de software que se utiliza principalmente para procesos de desarrollo e implementación de aplicaciones Java. Fue desarrollada originalmente en el año 2000 por la Apache Software Foundation.

Ant permite automatizar el proceso de creación de proyectos de software. Esto incluye compilar código fuente, escribir documentación, realizar pruebas y otras tareas relacionadas con la preparación del software para su distribución.

Apache Ant es una herramienta de línea de comandos basada en Java para construir aplicaciones Java con la portabilidad total de puro código Java. Permite a los desarrolladores adoptar principios ágiles y desarrollo basado en pruebas para automatizar las tareas de desarrollo repetitivas, como generar documentación, entre otras.

Características Principales de Apache Ant

Ant fue creado para gestionar de manera eficiente el ciclo de vida del software, y todas las automatizaciones de las que dispone van encaminadas a la consecución de dicho objetivo. Por tanto, las características principales de Ant están relacionadas con esta idea:

• Automatización de Tareas: Ant permite automatizar diversas tareas relacionadas con el desarrollo de software, como compilación, empaquetado, pruebas, despliegue y más.
• Build Scripts: Ant utiliza archivos de configuración XML llamados "build scripts" para definir las tareas y la secuencia de comandos a ejecutar durante el proceso de construcción. Estos archivos de construcción son portables y pueden ser fácilmente compartidos y reutilizados entre diferentes proyectos.
• Independencia de Plataforma: Ant es independiente de la plataforma, lo que significa que los archivos de configuración XML creados en un sistema operativo pueden ejecutarse en otros sistemas operativos compatibles con Java. Esto facilita la transferencia de proyectos entre diferentes entornos.
• Extensibilidad: Ant es altamente extensible y permite la integración con otras herramientas y bibliotecas mediante complementos y extensiones personalizadas.
• Integración con IDEs: Ant se puede integrar con varios entornos de desarrollo integrado (IDE), como Eclipse, IntelliJ IDEA y NetBeans, lo que facilita la construcción y el desarrollo de proyectos dentro de estos entornos.
• Basado en Tareas: El funcionamiento de Ant se basa en la ejecución de tareas, que son unidades de trabajo individuales que realizan acciones específicas, como compilar archivos Java, copiar archivos, ejecutar pruebas, etc.

Módulos de Trabajo de Apache Ant

Una vez revisadas las características anteriores, podemos continuar indicando que Apache Ant se compone de los siguientes módulos de trabajo:

• APACHE ANT CORE: Este módulo es la parte central del proyecto Apache Ant. archivos de construcción (build files). específicos que ocurren durante el proceso de construcción. nuevas tareas utilizando el lenguaje XML.

La clave para el trabajo de Ant es la creación de tareas que van a realizar un determinado trabajo en nuestro proyecto. Las tareas a ejecutar por Ant deberán ser incluidas en un fichero XML genérico que se va a convertir en la parte central del despliegue de la aplicación. La denominación estándar de este fichero es build.xml.

Este es el directorio desde donde se calcularán todas las rutas. Se define el objetivo predeterminado para este proyecto. Es un fragmento de código que se puede ejecutar. Implementación de una compilación configurable con la ayuda de archivos de propiedades predeterminados y de compilación. Se puede invocar fácilmente a ant desde la línea de comando. Ant es una herramienta de compilación basada en XML. Una tarea es un fragmento de código que se puede ejecutar.

Ventajas Empresariales de Usar Apache Ant

El uso de Apache Ant ofrece varias ventajas empresariales, especialmente para proyectos Java:

1. Ayuda a gestionar las dependencias entre los diferentes componentes del proyecto.
2. Facilita la implementación de aplicaciones definiendo y realizando tareas específicas para empaquetar e implementar aplicaciones de manera consistente.
3. El uso de archivos XML para definir tareas y parámetros del proyecto proporciona flexibilidad y legibilidad a la hora de definir las tareas a realizar. Los desarrolladores pueden personalizar fácilmente las tareas según los requisitos del proyecto.
4. Ant es multiplataforma, lo que significa que se puede utilizar en una variedad de sistemas operativos sin cambios importantes en el script de compilación.
5. Se integra bien con otras herramientas y entornos de desarrollo.
6. Puede escalar y adaptarse a proyectos de diferentes tamaños y complejidad. Desde pequeños proyectos hasta grandes aplicaciones empresariales, Ant proporciona un marco confiable para gestionar los procesos de compilación.

Apache Ant en Comparación con Otras Herramientas de Construcción

Sin duda Ant, Maven y Gradle son las herramientas de automatización de construcción que se utilizan en proyectos Java más populares en el mundo. En un inicio, Make era la única herramienta disponible para automatizar la construcción de nuestros programas, bueno además de las soluciones que se desarrollaron por cuenta propia. Make ha estado presente desde 1976 y fue usada para construir las aplicaciones en los inicios de Java. Sin embargo, un montón de convenciones de los programas hechos en C no cabían en el ecosistema Java, así que con el tiempo Ant se convirtió en una mejor alternativa.

Actualmente se encuentra en declive, debido a que en los desarrollos actuales se ha ido imponiendo la utilización de Maven. Sin embargo, todavía podríamos encontrarnos con ella en proyectos creados hace más de 10 años.

Apache Ant vs. Rake

Si no quieres escribir tu propia herramienta, puedes usar Rake. Rake es la mejor herramienta de construcción para proyectos Java. Proporciona un montón de métodos estándar para desarrollar las tareas de construcción más comunes, y cualquier cosa puede ser implementada rápidamente en Ruby. La gran ventaja de Rake sobre otras herramientas es que puede escribir scripts en un lenguaje de programación real. De esta manera puedes escribir y personalizar herramientas de construcción para tus proyectos. Si no quieres puedes usar Rake. Si no quieres cambiar, deberías. Si te falta coraje, entonces usa Ant.

Ant es la segunda mejor herramienta de construcción existente para proyectos Java. Es inferior a Rake, Ant sigue siendo una gran herramienta de construcción. Es maduro y estable, es rápido y viene con una rica librería de tareas. Puedes escribir tu propia herramienta de construcción o cambiar a Rake, o pelear por cambiar a Rake, o irte a algún lugar donde puedas usar Rake. Mientras Rake y Ant pueden acomodarse a cada proceso de construcción, Maven no.

Apache Ant vs. Maven

Las construcciones de Maven son una desesperación infinita que lentamente te arrastrará al más profundo pozo de oscuridad del infierno (donde Maven fue forjada). Inicialmente tardarás 10 minutos en instalar y arrancar Maven, podrás ser feliz con él durante algún tiempo. Pero a medida que el proyecto evoluciona, y tu configuración de construcción crece, el elemental pom.xml que iniciaste resultará inadecuado. En serio, Maven es una implementación horrible de malas ideas. Creo que alguien en alguna lugar tenía (quizás todavía tiene) una visión de Maven que era razonable, sino seductora. Pero la actual implementación de Maven carece de cualquier vestigio de dicha visión. De hecho cada cosa en Maven está tan mal, que se sirve de ejemplos de como no hacer software.

Problemas con Maven

• Informes de Pruebas: Tenga en cuenta la salida de resultados de pruebas del plug-in Surefire de Maven. Todo parece bien cuando las pruebas se están pasando, pero los informes de Surefire son una pesadilla para depurar cuando las cosas van mal. La única información conectada a la consola es el nombre del test que ha caído. Manualmente tienes que hacer una referencia cruzada con el nombre que se ha grabado en el fichero log, que se encuentra en el directorio target/surefire-reports, ¡pero estos logs están escritos uno por test!, así que si fallan múltiples test, deberás separar múltiples ficheros logs.
• Convención sobre Configuración: Los defensores de Maven reclaman que la herramienta cumple el Principio de la Convención sobre Configuración. Mienten. La única convención que soporta Maven es: compilar, ejecutar test unitarios, paquetes .jar. Usar Maven para hacerlo todo requiere configurar las convenciones. ¿Quieres empaquetar un fichero .war?, configúralo. ¿Quieres ejecutar tu aplicación desde la línea de comandos?, configúralo. ¿Quieres ejecutar test de aceptación o test funcionales o desarrollar test con tu ‘build’?, configúralo, esto implica no ejecutar los test unitarios, o no ejecutarlos mientras dura la fase convencional de test unitarios del proceso ‘build‘. ¿Quieres generar un indicador del estado del código para tu proyecto?
• Configuración Compleja: Como consecuencia, la configuración de Maven es abundante, difícil de leer y de escribir. No hay nada coherente en la configuración de Maven. Algunas cosas son configuradas como ‘classpath references‘ (una referencia desde la ruta donde se encuentra la clase) hacia los ficheros ‘.properties’ construidos en ficheros ‘.jar‘ configurados como dependencias, algunas son configuradas como rutas absolutas o relativas de los ficheros en el disco y algunas son configuradas como propiedades del sistema en la JVM cuando se ejecuta Maven. Y algunas de estas rutas relativas son portadas a través de los proyectos porque Maven conoce como resolverlas correctamente, pero otras no.
• Configuración Fragmentada: ¡Algunas cosas no son configuradas en el pom.xml!, como los repositorios Maven, los servidores, las credenciales de autentificación, que son configuradas en el fichero settings.xml. Es perfectamente razonable querer mantener el usuario y contraseña fuera del fichero pom.xml pues será comprobado dentro del repositorio de control de versiones del proyecto. Pero Maven tiene una solución terrible, toda la configuración está en el fichero settings.xml que vive fuera de cualquier directorio del proyecto. No puedes compartir directamente cualquiera de las configuraciones entre tu sobremesa y tu portátil, o con cualquier desarrollador, o con el servidor de tu proyecto. Pero es automáticamente compartido con cada proyecto único de Maven con el que trabajes y potencialmente con cada usuario que use el ordenador. Cuando un nuevo desarrollador se una a tu proyecto, deberá cambiar manualmente la configuración necesaria en el fichero settings.xml. Cuando un nuevo agente es añadido a tu granja de servidores, la configuración necesaria es manualmente fusionada en el settings.xml existente. Del mismo modo cuando quieras migrar a un nuevo ordenador. Y cuando cualquiera de estas configuraciones necesiten actualizarse, debe actualizarse manualmente en cada máquina. Esto estaba ya resuelto antes de que Maven llegase, también los archivos de propiedades.
• Falta de Documentación: Todas estas cosas en Maven -convenciones, configuraciones y procesos- son gobernados a la manera Maven. Desafortunadamente «la manera Maven» no está documentada. Puedes encontrar algo fugaz buscando en la documentación de Maven, en Google, o comprando libros escritos por los desarrolladores de Maven. Otra manera de encontrar «la manera Maven» es tropezando con sus invisibles fronteras.
• Falta de Flexibilidad: Maven no fue creado para ser flexible y no soporta cada posible proceso de creación (‘build’). Fue creado para los proyectos de Apache, y asume todos los procesos espejos de construcción de proyectos de Apache como propios. Es una noticia genial para los desarrolladores open-source quienes voluntariamente en su propio tiempo entienden que liberar (‘release‘) significa subir un fichero ‘.zip‘ a la web, para que otros manualmente lo encuentren, lo descarguen y lo añadan a sus propios proyectos. Es una faena para todo lo demás.
• Gestión de Dependencias Rota: La gestión de dependencias que tiene Maven está completa, total e irrevocablemente rota. Actualmente, retiro lo dicho; la estrategia de Maven de descargar la biblioteca al directorio del usuario y volcarlo en el ‘classpath’ es increíblemente estúpido y equivocado y nunca debería ser confundido con «gestión de dependencias». Recientemente trabajé con Maven en un proyecto que produjo un fichero ‘.war‘ de 51MB; Cambiando a Ant, con gestión de dependencias, reducimos a menos de 17MB. Las dependencias extrañas no solo consumen espacio en disco, consumen también la preciosa RAM.
• Alto Consumo de Recursos: Maven es un traga memoria. Relativamente, proyectos simples, con solo un pom.xml y unos pocos submódulos requiere una extensa memoria de la JVM con todas las fantásticas opciones de JAVA_OPTS; esto solo lo puedes ver en los servidores de producción. Las cosas empeoran si tu construcción Maven está integrada en tu IDE. Es muy común aumentar el tamaño de la memoria dinámica de la JVM a cientos de megabytes, el tamaño máximo ‘permgen‘ a unos pocos cientos de megabytes, permitir a ‘permgen‘ generalizar el recolector de basura de las clases.
• Rendimiento Lento: Una historia bonita: en ese mismo proyecto, Maven tardó diez minutos en hacer un ‘mvn clean‘ porque pensaba que necesitaba más basura «rm -rf ./target/«. Actualmente no hay ninguna bonita historia, créeme, no quieras construir una herramienta que automáticamente descarga dependencias no resueltas antes de limpiar los directorios de construcción. Y todo innecesariamente, sobrecargando de red. Pagas una penalización en el rendimiento, Maven rompe la gestión de dependencias en cada construcción. 10 minutos para limpiar la construcción es horrible, pero añadir unos minutos extra para cada construcción es aún peor. Estimo que la sobrecarga promedio adicional de Maven es de aproximadamente un minuto por cada construcción, basado en el hecho de que la única vez que cambié Maven por Ant, la media del tiempo de construcción se redujo de dos minutos y medio a uno y medio.
• Falta de Control y Visibilidad: No tienes el control, tienes poca visibilidad de lo que pasa dentro, las dependencias se especifican por tus dependencias. Los ‘builds‘ se romperán por las diferentes copias que Maven descargará de diferentes artefactos en diferentes momentos. Tu ‘build‘ local se romperá de nuevo en el futuro cuando las dependencias de tus dependencias accidentalmente lancen nuevas, no compatibles hacia atrás con los cambios, sin recordar poner el número de versión. Estos son fallos inocentes. El escenario más probable es que tu proyecto depende de versiones específicas de algún otro proyecto que tendrá dependencias de versiones antiguas de algún otro proyecto. Pero Maven es incluso peor, no solamente resuelve automáticamente las dependencias de tu proyecto, también resuelve automáticamente las dependencias de sus plugins.
• Agujero de Seguridad: La mala gestión de dependencias de Maven también tiene un enorme agujero de seguridad, desde el cual actualmente es imposible determinar de donde provienen los artefactos y si han sido o no manipulados. Los artefactos tienen una suma de comprobación (‘checksum‘) automática cuando son subidos a un repositorio, Maven automáticamente verifica que la suma de comprobación cuando descarga el artefacto, pero implícitamente confía la suma de comprobación en el repositorio desde el cual se ha descargado. El alcance actual de la seguridad de los artefactos en Maven es que los desarrolladores de Maven controlan quién tiene acceso de escritura para el repositorio autorizado en la ibiblio. Estos problemas no son causados por desarrolladores temerarios, y no se solucionan usando un gestor de repositorios para bloquear todo artefacto que Maven necesite.

Conclusiones sobre Maven

Maven está arruinado y mal enfocado, y asume que los humanos nunca cometen errores. Maven está arruinado y mal enfocado si requieres que los usuarios explícitamente especifiquen cada versión de cada dependencia, para reducir la probabilidad de descargarse artefactos incompatibles. Maven está arruinado y mal enfocado si requiere una tercera herramienta para prevenir que se conecte y se descargue mierda. Maven está arruinado y mal enfocado si piensa que no es lento descargarse cada ‘build‘ conectándose a la red y comprobando cada dependencia de cada actualización y descargándolo automáticamente. Maven está arruinado y mal enfocado si se comporta de manera diferente en mi portátil de la oficina y en el de casa. Maven está arruinado y mal enfocado si requiere una conexión a internet para eliminar un directorio.