jueves
ago142014
¿Merece la pena migrar de Ant a Maven en proyectos antiguos?
jcarmonaloechesBuenos días,
En la informática española, nos encontramos que mucha parte del trabajo son proyectos de mantenimiento. Dichos proyectos suelen no estar situados, tecnológicamente, en nivel de vanguardia. La cuestión que yo me planteo, en la actualidad, ¿es conveniente, en un proyecto antiguo, estabilizado con un gestor de configuración como Ant, migrar a una herramienta como Maven? ¿Qué pros y contras tendría este cambio?
Agradecería diferentes puntos de vista al respecto para favorecer el debate.
Saludos cordiales,
Reader Comments (22)
Yo seguiria la primera norma "si funciona no lo toques"
Seguidamente me haría las siguientes preguntas:
Es un proyecto que he de tocar mucho en un futuro?
Que beneficios me aporta el cambio de ant-maven?
y otra cosa Maven puede hacer correr configuraciones de ant. por lo que podría llegar a tener un pom.xml con un build.xml de ant, teniendo las 2 tecnologias trabajando a la vez.
salu2
Cambiar por cambiar... no me parece. Si con ANT cumple con todas las necesidades (que probablemente lo hace), no lo cambiaría.
Ni tampoco usaría ANT en un proyecto nuevo, pero si un proyecto antiguo ya lo usa, y está estable y con poco o nulo mantenimiento, no le haría grandes cambios ahora si no hay otros motivos.
Otro tema sería, si aprovechando alguna reingenía importante del proyecto, quieras cambiar de paso para tener todos los proyectos gestionados de la misma forma. Como de todas formas habrá una prueba más extensa, sería un buen momento.
Es cuestión de considerar qué se gana, y cuánto cuesta (considerando todo: horas de prueba, etc).
También se puede ir a una solución híbrida: hay un plugin de maven para ant. De nuevo, dependerá del caso si la vale la pena.
La ventaja de Maven es el manejo de dependencias, y la descarga automática de todos los jars desde los repositorios internos y externos. Además, se pueden quitar los jars del svn/git si es que estaban allí. Puede ser una ventaja o una desventaja, según como se mire.
Si funciona y bien, no lo rompas :) Si cambiarlo te va a ahorrar tiempo (y por ende costos) entonces perfecto. Sino, busca mejoras que si brinden algo tangible para los usuarios ;)
Antes de migrar a otra herramienta de construcción me preguntaría ¿usar ant en el proyecto antiguo causa algún problema? ¿va a aportar algo salvo usar algo más moderno y mejor? Ya sabes, si funciona no lo toques.
Pero si hay que migrar a algo, de hacerlo, lo haría a gradle [1] mucho antes que a maven, maven también puede considerarse ya antiguo. gradle tiene las ventajas de ant (flexibilidad) y maven (gestión dependencias, convenciones) sin sus inconvenientes (xml y poca flexibilidad de maven).
[1] Pequeña introducción a la herramienta de construcción Gradle
Hola picodotdev, gracias por el aporte.
La verdad es que hace unos años era partidario de cambiar cualquier proyecto a la tecnología más avanzada, pero creo que ahora mido más el riesgo de cambio.
Muy interesante el aporte de Gradle, a tener en cuenta. ¿Sabes si tiene una curva de aprendizaje alta?
Un saludo,
Si quieres gestión de dependencias en Ant no hace falta ir a Maven o gradle , puede usar Ivy desde Ant.
Diría que no, para lo básico no cuesta mucho y viendo algún ejemplo o siguiendo un poco la documentación es suficiente ya que utiliza convenciones y son parecidas o iguales a las que se usan en maven, tampoco es necesaria mucha configuración. Pero como todo para un caso complejo hay que dedicarle más tiempo, en cualquiera caso el tiempo que te cueste hacer algo en gradle casi seguro que es mucho menor que en ant o maven y con bastantes menos problemas o limitaciones.
Personalmente me encanta maven, hasta que tengo que hacer algo medio raro y empieza la lucha con los plugins.....
Pasar de ant a maven no lo veo complejo, sobre todo porque una vez que tenés la estructura que recomienda maven, hay un plugin (creo que era maven-ant-run) que te ejecuta ant, con lo cual en principio podrías tener todo lo que antes hacías con ant con maven e ir pasando de a poco a los plugins de maven.
Con respecto al comentario de picodotdev de tomar al xml como un inconveniente, hasta ahora no he encontrado un solo punto en contra a esto, pero supongo que es cuestión de gustos (para mi, xml es mucho mas legible que json o algún otro formato)
En cuanto a flexibilidad, yo creo que maven es muy flexible y que el problema no es maven en sí sino los plugins que hay cada uno que mejor ni mirarlo.....
Te aclaro que esto lo comento desde el lugar de haber trabajado con maven desde el 2007, de tener que hacer un plugin para maven, de bajarme el código y meterle mano a alguna clase y de cambiar de trabajo y sin dudar empezar a meter maven en donde pueda
Saludos
Pues yo estoy con picodotdev. ¿Es que ant no funciona? No es solo por el "si funciona no lo toques", que es importante, si no porque la discusion ant/maven es algo que no tiene nada que ver con la funcionalidad del proyecto, que es por lo que nos pagan, si no con lo del alrededor, el como se compila el proyecto.
¿Pasar un rato migrando de ant a maven va a hacer mas feliz al cliente? ¿Va a hacer que la aplicacion funcione mejor? Si necesitas gestionar las dependencias, usa Ivy, que te costara poco, aunque en un proyecto viejo supongo que apareceran pocas dependencias nuevas y probablemente incluso meter Ivy te cueste mas que tocar el XML para poner un jar nuevo de vez en cuando.
En fin, que en mi opinion, no merece la pena.
Muchas gracias a tod@s por vuestra opinión.
Ant funciona muy bien, está muy probado, quizá mola menos que Maven, pero, si el cambio de dependencias (en algo muy estabilizado, donde los cambios son menores que en nuevos desarrollos) no es alto (como se ha comentado previamente), ¿realmente merece la pena? Ciertamente, siempre mola hacer uso de tecnologías más molonas / nuevas (de hecho, a mi siempre me pica el gusanillo), pero.... ¿cómo podría justificarlo, en este caso, hacia un superior, con algo concreto?
No es tarea fácil no.... ¿Realmente es útil, aporta? Deciros que el no innovar me genera una frustación considerable... pero la realidad externa es otra cosa.
Un saludo a tod@s.
Personalmente, coincido tanto con picodotdev en lo de aplicar la primera ley de ingeniería (si funciona no lo toques). Como con nilojg en su análisis estilo problema B8 (si el costo de tratar de evitar un fallo es mayor al de resolver el fallo, pues resuelve el fallo en lugar de evitarlo).
Recordad siempre que un buen PM es quien administra bien sus recursos, y no el que está permanentemente innovando.
Particularmente cuando esa innovación complica (o va a contramano) del mantenimiento evolutivo.
Un saludo.
Coincido esencialmente con lo comentado en la mayor parte de los comentarios. Maven aporta, fundamentalmente, una estructura normalizada de construcción de proyectos. Algo que puede ser muy interesante a la hora de desarrollar un proyecto nuevo, pero que puede ser un dolor de cabeza si de lo que se trata es de migrar la estructura de tareas de ant a la estructura normalizada de Maven.
No obstante hay determinadas capacidades específicas de Maven que puede ser interesante llevarse a un proyecto gestionado por Ant, como es la gestión de librerías (y sus dependencias) a partir de repositorio central. Esto en Ant se hace con el plugin Ivy e, incluso en proyectos antiguos merece la pena esta adaptación.
Saludos.
Hola de nuevo, muy acertada la frase de Eduardo:
"Recordad siempre que un buen PM es quien administra bien sus recursos, y no el que está permanentemente innovando" aunque la de caras largas que tendrá que soportar por tomar esta actitud... (incluso críticas).
Por otro lado, sobre Maven, lo comenta vellebue, es correcto el hecho de que Maven "normaliza" la estructura de paquetes, lo que ayuda, y obligaría a que si quieres adaptar estos proyectos a esta nueva estructura, tengas que hacer ese trabajo. Por otro lado, la ventana de automatización de inclusión de estructuras, a mi manera de ver, es interesante y una ventaja en el caso de que se quiera aplicar inclusión de nuevas librerías, y, a mi modo de ver, el grado de inclusión sea medio / alto (si estimas incluir una librería, quizá no merezca la pena combinar la gestión de librerías de Maven con las que antiguamente tenías incrustadas en el proyecto.... y migrar las antiguas que tenían integradas a la gestión de configuración de Maven, tiene el grado de incertidumbre de que en muchas ocasiones, se desconoce la versión de las librerias descargadas, puesto que no aparece la versión normalizada en el nombre).
Sobre Graddle, no conozco mucho (lo miraré e intentaré dar mi punto de vista). Otra buena pregunta que me surge es si Ant ofrece funcionalidad que los plugins de Maven no ofrecen (salvo a través de la ejecución del plugin de Ant, que, en ese caso, tener dos gestores de configuración de software en un mismo proyecto puede ya ser de por sí un antipatrón y estar contradeciendo los propios principios de calidad del software), y viceversa, ¿Maven ofrece funcionalidad mediantes sus plugins que no ofrece Ant?
Un punto de vista más (y)
¡Un saludo a tod@s y muchas gracias! (por cierto, muchas opiniones y parece que ninguna femenina, muy mal por ellas)
Buenas noches,
Quería pregunar por este tema a ver que opciones me podéis dar. Resulta que tengo jefe nuevo y ha decidido implantar CI en todos los proyectos que le tocan, el caso es que el 99% son proyectos WEB del neolítico y 1% ejb´s del pleistoceno, esto es... Eclipse-> New Project -> Web Dinamic Project...... Ni que decir que están que dan penita verlos. El caso es que llevo dandole vuelas a ver con que herramienta los puedo automatizar (ANT, MAVEN, GRADLE un simple script). A ver que me aconsejais. Muchas gracias.
Sobre el post inicial: Yo realice en su día en un proyecto de la época de struts, hace unos dos años un cambio de ant a maven y la tarea merece la pena y no es trivial.
- La ventaja de maven como ya se ha comentado es que te estandariza el proyecto y te monta un ciclo de vida ademas que tiene una gestión muy potente de las librerías ademas de plugins.
- La estandarizacion te permitirá poder importar tu proyecto en varios ides de manera facil.
Unos consejos o casa a tener en cuenta al migrar un proyecto de ant a maven (En un entorno empresarial) para que no se convierta es un infierno :) .
- Montar un servidor que haga de repositorio como por ejemplo (Artifactory, nexus, archiva etc), sobre cual es el mejor eso va por gusto, en mi caso particular como son pocos proyectos y lo conocía use artifactory. Pero la peña habla muy bien de nexus. Una vez montado configurar los equipos de maven para que enganchen con el repositorio y no con internet directamente. Este punto que puede parecer una fricada es la diferencia entre el fracaso o no de montar maven, ya que lo que pretendemos es que el proyecto se pueda montar en entornos nuevos sin tener que ñapear cosas. Ademas en todos los proyectos por los que he pasado un porcentaje pequeño de las librerías no están en los repositorios de maven sobre todo en los proyectos antiguos, y estas herramientas te solventan el problema.
- Revisar las librerías que te baja maven con las de tu proyecto, acordarse que una dependencia puede bajar varios .jar (Ojo con esto, existe un sistema para excluir), esto esta muy bien pero te puedes encontrar con versiones diferentes de librerías o con mas de las que usaba tu proyecto (Esto es importante en las migraciones).
- Y si alguna tarea no puedes o no encuentras como resolverlas con maven siempre puede utilizar algo de ant (No es recomendable).
Yo para pasar 100% un proyecto con mas de 8 años de desarrollo y un tamaña considerable tarde en montar todo el chiriguito, es montar la infraestructura(Artifactory, configurar tareas de jenkins y que el sistema estuviera operativo en todos los equipos de desarrollo sin ñapas). Una semana mas o menos en dejar el tema terminado y finiquitado.
Nota: Sobre usar Gradle, la verdad que no tenga experiencia, pero ya el paso de ant a maven es un gran avance. Aquí os paso un articulo interesante sobre maven y gradle explicando algunos conceptos y que aporta cada uno gradle-maven-perspective
Nota 2: Tenéis que acostumbraros a como funciona maven su ciclo de vida, para que no os vuelva locos y la farma de como estandariza los proyectos.
PD: Espero que te sirve de ayuda.
En mi caso empezamos un proyecto gubernamental en el 2004 con Ant, a mediados del 2005 migramos a maven (1) con muchos inconvenientes y con una gran cuota de soporte. Lo cual nos llevo a plantearnos si era la herramienta correcta para el proyecto. En el 2006 iniciamos un desarrollo propio y sacamos Maven porque se había convertido en una tortura, no escalaba a la cantidad de proyectos, la integración con Eclipse era inexistente, y luchar con Jelly...
Encarar el nuestro herramienta de autiomatización nos permitio integrar mejor nuestro ambiente de desarrollo y focalizarnos en las cuestiones que nos resultaban más útiles. Bajo notablemente las horas de soporte y cambiamos las horas de soporte por horas de nuevas funcionalidades. Actualmente seguimos usando la misma herramienta.
Para que se den una idea del tamaño que hablo, actualmente contamos con 215 componentes con un promedio de 3.5 subcomponentes (proyectos java) cada uno.
Ant nos resulto muy confiable y muy estable una vez que se logran los targets necesarios.
Maven nos dio algunas ideas con lo que arrancar, y unos cuantos problemas para darnos cuenta qué cosas no hay que hacer.
Saludos
Hola Luis, varios apuntes, según se ha visto en este hilo (por favor, si me columpio y alguien se da cuenta, corregirme).
1) "Si funciona y no quieres arriesgar, no lo toques". Entiendo que estás en Ant.
2) Existe la posibilidad de que convivan Ant y Maven, o bien Ant y Graddle, para que no te afecte o corte el desarrollo del día a día. Así mismo, Ant mediante Ivy proporciona gestión de dependencias.
3) Parece que los POM de Maven, al final, se pueden complicar bastante (a nivel de legibilidad). Hay gente que ve Gradle más legible en este sentido (al menos, sus ficheros de configuración declarativos, parecen más manejables).
4) Ant no define una estructura de proyecto (especificas tú la misma en el fichero de configuración) y parece que Maven y Gradlle normalizan esa estructura de proyecto. Si quieres cambiar de herramienta, posiblemente te toque readaptar el código a la nueva estructura. Sobre Gradlle no estoy seguro, he leído que tiene su propia estructura de proyecto pero puede que en el fichero de configuración puedas definir de donde leer el código fuente y similares.
5) Gradlle se basa en Groovy, parece ser, mientras que Maven en Java. Ambos permiten extender funcionalidad mediante plugins.
A mi modo de ver, Graddle es el que más "moderno" es, ahora bien, quizá cueste un poco aprenderlo. Gradlle y Maven los veo similares en potencialidad, mientras que Ant creo que es más "a medida" y puede atar un poco. Quizá por escalabilidad me quedaría con Gradlle (los ficheros de configuración son un poquito más legibles), pero tendría en cuenta si tengo tiempo de aprendizaje y eso no afecta al día a día.
Un saludo,
A título informativo, y tomado de la encuesta sobre plataformas tecnológicas, (no crea que esto allá cambiado sustancialmente desde el 2012)
Del apartado "Build Tools".
A nivel global el 82,55% de los participantes emplea una o más de un total de 9 herramientas distintas, mientras que un 17,45% no requiere de ellas.
Aplicado el filtro del 10%, la lista se reduce a tan solo 2, siendo Apache Maven la más utilizada con un 58,05% del total registrado.
ANT ocupa el segundo lugar con un nivel de adopción del 44,13%.
¿graddle? tiene un nivel de adopción del 2,69% muy por debajo del 4.56 del make.
Ver las graficas de apertura por país.
Un saludo,
En opinión creo que es esencial introducir CI en todos los proyectos, aunque sea muy básico y simplemente para la construcción de los artefactos finales (war, jar, ear, arr,...), Desde mi punto de vista todo operación manual en la construcción del artefacto final es propensa a errores y debe ser automatizada.
A partir de este punto luego se puede ir automatizando todo lo demás, gestión de dependencias, test servidor, test cliente, despliegue en el entorno de deseado, etc...
Si lo quieres profesionalizar más puedes incluso instalar tu propio servidor de dependencias, Nexus Sonatype, sobre todo en entornos en donde no se tiene salida a internet el poder poner todas tus dependencias en tu propio servidor es una ventaja.
Y luego también puedes combinar tecnologías yo ANT para realizar toda la configuración de compilado, test, empaquetado y despliegue pero maven como gestor de dependecias. Los servidores CI como Jenkins te permiten usarlo en combinación y incluso también existen librerías de ant para integrar funcionalidades de maven dentro de ant como instalar un artefacto.
Para @Luis.
Si ya tienes proyectos creados yo creo que lo mejor es adaptarlos al CI con ANT ya que todo lo programas tú, para los nuevos ya los generaría a través de MAVEN ya que te da la estructura más organizada y el standard. Sobre GRADLE tengo que mirarlo más a fondo pero intuyo que es similar a MAVEN.
Saludos.
Hola Eduardo, personalmente, me sigo sintiendo atraído por Gradlle, el hecho de que no sea la herramienta más utilizada no creo que sea un motivo para que sea descartada (a no ser que el jefe de proyecto ponga esta restricción). Más que por volumen de uso, me fijaría si es la herramienta con que más me atrae. Por otro lado, veo que dicho informe es positivo para conocer el estado actual de dichas herramientas.
Estoy de acuerdo con la visión de CI de @antuansoft.
Un saludo,
Hay un detalle que quisiera comentar. Maven no te obliga a usar una determinada estructura de proyecto. Por defecto, te proporciona una, que es la que la mayoría de la gente utiliza, y es lo recomendable en proyectos nuevos (facilita el entender dónde están las cosas, al cambiar de un proyecto a otro). Pero eso es configurable. Para lidiar con proyectos viejos, se puede configurar el POM para indicar dónde está cada cosa. Dependiendo de lo que se aleje la estructura del proyecto del estándar Maven, será más o menos tedioso, pero se puede hacer.
Gracias @adeteran, creo que el esquema es el siguiente:
-Maven y Gradlle "proponen" una estructura fijada (estandarizan), pudiendo customizar la misma.
-Ant, en principio, no propone dicha estrcutura, es decir, te obliga a definirla en el fichero de configuración.
Pero es la idea que tengo, me gustaría confirmarlo sobre ejemplos reales. Cuando lo sepa, os lo confirmo.
Un saludo,
@Jaime
Por eso aclaré que era a título informativo.
;)
Retomando el comentario de antuansoft (y a título personal).
La automatización de los procesos de compilación, documentación, armado de paquetes (los "artefactos"), deploy, y el control de versiones, es algo tan básico que debería ser obligatorio.
Una práctica por demás recomendable está en la separación de ambientes (QA, developl y producción ). Y en mi caso es obligatoria (ningún desarrollador tiene acceso a producción y ningún usuario tiene acceso a los ambientes de desarrollo)
Otra buena practica (y que aparentemente nadie sigue) está en tener un ambiente de testing evolutivo. No solo por el tema de versioning de librerías, sino también por lo relacionado a aplicación de parches, versiones de la JVM, del motor de DB, etc., etc., etc., etc.,..
Una vieja discusión (y recurrente hasta el hartazgo) sobre este tema está en si este ambiente de testing evolutivo es responsabilidad del área de desarrollo (como dice la gente de soporte) o si pertenece a la órbita de soporte / infraestructura (quienes aplican los parches de seguridad y las actualizaciones de software sin preguntar ni avisar a nadie).
En cuanto a lo de aplicar integración continua en un proyecto estilo YO-YO (yo me lo hago, yo me lo cómo, yo me intoxico), o que originalmente no solo no cuenta con casos de testing modular, si no que además sus reglas de negocio no fueron pensadas para ser acopladas en un proceso de testing automatizado, .................
Pues, buena suerte..
Un saludo,