java - plugin - Migración de un proyecto complejo de Ant a Maven: ¿cómo manejar estructuras de carpetas inusuales?

maven vs gradle comparacion (2)

En mi nuevo proyecto, me encuentro con una infraestructura compleja con varios módulos que han crecido a lo largo de los años de una manera desagradable e incontrolada.

Para llegar al punto: el proceso de construcción es el horror. Existen más de 40 archivos Ant diferentes y complejos, que están conectados varias veces y el marco SOA también genera varios archivos Ant dinámicos. Tomó unos días entender realmente todas las dependencias y finalmente construir todo el proyecto sin ningún error.

Mi plan era o es migrar todo el proyecto de Ant a Maven, ya que se planean nuevos componentes y me gustaría evitar estos problemas en el futuro y bueno, porque es horrible como está ahora ;-)

Como soy nuevo en la migración de proyectos más grandes, estoy un poco confundido sobre el mejor flujo de trabajo. Hay docenas de archivos XML y scripts involucrados, que se distribuyen en una estructura de directorios no Maven. En general, hay más de 3000 archivos involucrados. Uno de los principales problemas es que no sé si realmente debería intentar migrar todo en la estructura de directorios conocida de Maven y, por lo tanto, arriesgar la edición y refactorización sin fin de cada archivo. ¿O debería mantener la estructura de carpetas tal como está e hinchar mis archivos pom.xml y posiblemente tener problemas con los diferentes plugins involucrados? Honestamente, ambas formas no parecen muy constructivas.

¿Tiene sentido incluso migrar un proyecto en esta dimensión a Maven? Especialmente cuando el marco SOA debe usar sus propios archivos Ant; por lo tanto, sería necesaria una combinación de Ant y Maven. ¿Cuál sería la mejor estrategia para simplificar este proceso?

Gracias por todas las sugerencias.

Aquí hay una respuesta simple y rápida al proyecto Mavenizing an Ant:

¡NO LO HAGAS!

Esta no es una regla anti-Maven. Uso Maven, y me gusta Maven. Obliga a los desarrolladores a no hacer cosas estúpidas. Los desarrolladores son terribles al escribir scripts de compilación. Quieren hacer las cosas de esta manera y no de la manera en que lo hacen los demás. Maven hace que los desarrolladores configuren sus proyectos de una manera que todos puedan entender.

El problema es que Ant permite a los desarrolladores hacer cosas locas y alocadas que tienes que rehacer por completo en Maven. Es más que solo la estructura del directorio. Ant permite múltiples artefactos de construcción. Maven solo permite una por pom.xml ¹ . ¿Qué sucede si su proyecto Ant produce media docena de archivos jar diferentes y esos archivos jar contienen muchas de las mismas clases? Tendrás que crear una media docena de proyectos Maven solo para los frascos, y luego otra media docena para los archivos que son comunes entre los frascos.

Lo sé porque hice exactamente esto. El jefe de Arquitectura del Sistema decidió que Maven es nuevo y bueno, mientras que Ant debe ser malo y malvado. No importaba que las construcciones funcionaran y estuvieran bien estructuradas. No, Ant debe irse, y Maven es el camino.

Los desarrolladores no querían hacer esto, así que me cayó a mí, el CM. Pasé seis meses reescribiendo todo en Maven. Teníamos WSLD, teníamos Hibernate, teníamos varios frameworks, y de alguna manera, tuve que reestructurar todo para que funcione en Maven. Tuve que generar nuevos proyectos. Tuve que mover directorios. Tuve que encontrar nuevas formas de hacer las cosas, todo sin detener a los desarrolladores de grandes cantidades de desarrollo.

Este era el círculo más interno del Infierno.

Una de las razones por las cuales sus proyectos Ant son tan complejos probablemente tiene que ver con la administración de la dependencia. Si usted es como nuestra tienda actual, algunos desarrolladores decidieron ~~hackear juntos para~~ desarrollar su propio sistema de administración de dependencias. Después de ver este sistema de administración de dependencias, ahora sé dos cosas que los desarrolladores nunca deben escribir: sus propios archivos de compilación y sistemas de administración de dependencias.

Afortunadamente, existe un sistema de administración de dependencias ya existente para Ant llamado Ivy . Lo bueno de Ivy es que funciona con la arquitectura actual de Maven. Puede usar el repositorio Maven centralizado de su sitio, e Ivy puede implementar archivos jar en ese repositorio como artefactos Maven.

Creé un proyecto Ivy que configura automáticamente todo para los desarrolladores. Contenía la configuración y la configuración necesarias, y algunas macros que podrían reemplazar algunas tareas Ant estándar. Utilicé svn:externals para adjuntar este proyecto de Ivy al proyecto principal.

Agregar el proyecto al sistema de compilación actual no fue muy difícil:

Tuve que agregar algunas líneas en build.xml para integrar nuestro proyecto ivy.dir en el proyecto actual.
Tuve que definir un archivo ivy.xml para ese proyecto.
Cambié cualquier instancia de <jar y </jar> a <jar.macro y </jar.macro> . Esta macro hizo todo lo que hizo la tarea estándar <jar/> , pero también incrustó el pom.xml en el jar como lo hacen las compilaciones de Maven. (Ivy tiene una tarea para convertir el archivo ivy.xml en un pom.xml ).
Arranqué toda la vieja basura de administración de dependencias que el otro desarrollador agregó. Esto podría reducir un archivo build.xml en cien líneas. También arranqué todas las cosas que hicieron las compras y los commits, o las cosas de ftp''d o scp''d. Todo esto fue para su sistema de compilación Jenkins, pero Jenkins puede manejar esto sin ninguna ayuda de los archivos de compilación, gracias.
Agregue algunas líneas para integrar Ivy. La forma más fácil era eliminar los archivos ivy.xml en el directorio lib y luego simplemente descargarlos a través de ivy.xml . En conjunto, podría tomar una docena de líneas de código para ser agregadas o cambiadas en el build.xml para hacer esto.

Llegué al punto en el que podía integrar a Ivy en un proyecto en unas pocas horas, si el proceso de compilación en sí no era demasiado complicado. Si tuviera que reescribir build.xml desde cero, podría llevarme dos o tres días.

El uso de Ivy limpió nuestro proceso de construcción Ant y nos permitió muchas de las ventajas que tendríamos en Maven sin tener que realizar una reestructuración completa.

Por cierto, la herramienta más útil para este proceso es Beyond Compare . Esto me permitió verificar rápidamente que el nuevo proceso de compilación era compatible con el anterior.

Pasando a Maven de todos modos ...

Lo curioso es que una vez que has integrado tus proyectos Ant con Ivy, convertirlos en proyectos Maven no es tan difícil:

Limpie la lógica en su build.xml . Puede que tenga que volver a escribir desde cero, pero sin la mayor parte de la basura de administración de dependencias, no es tan difícil.
Una vez que se build.xml limpiado build.xml , comience a mover los directorios hasta que coincidan con la estructura de Maven.
Cambiar fuente para que coincida con la nueva estructura de directorios. Puede tener un WAR que contenga * archivos css en una ubicación no estándar, y el código esté cableado para esperar estos archivos en ese directorio. Puede que tenga que cambiar su código Java para que coincida con la nueva estructura de directorios.
Rompe los proyectos Ant que crean proyectos múltiples en proyectos Ant separados que cada uno construye un artefacto único.
Agregue un pom.xml y elimine el build.xml .

¹ Sí, sé que esto no es del todo cierto. Hay proyectos de Maven con subproyectos y superpoms . Pero, nunca tendrás un proyecto Maven que construya cuatro jarras diferentes no relacionadas, mientras que esto es bastante común en Ant.

He hecho una migración similar en el pasado, y tenía las mismas dudas que tenía; Sin embargo, opté por "mantener la estructura de la carpeta intacta y especificar las rutas en los archivos POM" y noté que no era tan malo como pensaba.

Lo que realmente tuve que hacer fue configurar apropiadamente el <sourceDirectory> y el <outputDirectory> y tal vez agregar algunos filtros de inclusión y exclusión, pero al final yo diría que incluso si el modo de Maven es realmente convencional sobre-configuración-ish y te hace la vida más fácil si sigues sus instrucciones sobre dónde colocar los archivos, en realidad no lo hace mucho más difícil si no lo haces.

Además, algo que realmente me ayudó cuando migré fue la posibilidad de dividir el proyecto Maven en módulos, que inicialmente utilicé para replicar la estructura Ant (es decir, tuve un módulo Maven para cada archivo build.xml) haciendo la primera etapa de la migración más simple, y luego cambié la agregación del módulo para que sea más significativo y más parecido a Maven.

No estoy seguro si esto realmente tiene sentido para usted, ya que no tenía ningún archivo Ant generado que pueda ser el mayor problema para usted, pero definitivamente seguiría este camino de nuevo en lugar de refactorizar y mover archivos a todas partes para Mavenizar mi estructura de proyecto