Bicosyes - since evermore… » Maven, entre el amor y el odio

Maven, entre el amor y el odio

Publicado por blaxter - 19 Jun 2007 a las 21:15

La plataforma para la creación de aplicaciones a nivel empresarial es por excelencia Java (truenos de fondo...). Por lo normal, en todas las aplicaciones reales y serias que se hacen sobre Java, una de sus principales dificultades es el conjunto (elección y organización) de tecnologías (en este lote incluyo librerías, drivers, plugins, plataformas, servidores, herramientas y un largo etcétera interminable y del cual desconoceré la mayor parte y tú, aunque creas lo contrario, seguro que también). Una vez pasado el largo planteamiento inicial del componente que se desea a realizar, toca mancharse las manos y ponerse a programar. En cuanto te empieces a dar cuenta estarás ante una monstruosidad que sino llega a ser por tu querido IDE (eclipse, netbeans, vim+par de cojones) no podrías compilar y ponerlo en funcionamiento ni en tus sueños eróticos (tarea no trivial, entre otras cosas, por todo el conjunto de tecnologías externas de las cuales se suelen usar). Si a esto le sumas la tarea, no muy rara de darse, de mover todo el proyecto a otro sistema, empezarán a aparecer por ahí curiosas variables y similares que hay que cambiar por que son dependientes de un sistema en concreto. En definitiva, el proceso de gestión y construcción del proyecto se convierte en un autentico infierno, solo comparable al uso de Internet Explorer (OMFG!).

Para suavizar e intentar facilitar todo esto, existen herramientas para automatizar todo el proceso, la más conocida y usada actualmente es Ant (Netbeans la usa para todo el proceso de compilación), pero solo hace falta abrir uno de sus ficheros de configuración, build.xml, de un proyecto aleatorio para empezar a plantearse que quizá va a ser peor el remedio que la enfermedad. Vamos que su configuración es de todo menos intuitiva. Y su curva de aprendizaje (y mantenimiento) es pareja a bailar claque con un oso asiático en celo en la espalda.

Ahora es cuando digo que maven es bueno, bonito y barato y nos soluciona la papeleta. En parte así es, mucho más simple y potente que Ant (Maven hace lo mismo que Ant, y ambos son proyectos de Apache, uno de ellos más nuevo que el otro, adivina cual...), en definitiva un digno sucesor de Ant, mucho mejor, aunque no perfecto. Antes de seguir hablando pondré un "hola mundo" que así ya se entiende mejor qué es todo esto. Atención al pom.xml (project object model):
$ mkdir HolaMundo && cd HolaMundo $ mkdir -p /src/main/java/com/bicosyes/hola # com.bicosyes.hola será el package $ cat > /src/main/java/com/bicosyes/hola/Hola.java << EOF package com.bicosyes.hola; public class Hola { public static void main(String [] args) { System.out.println("¡Hola mundo!"); } } $ cat > pom.xml << EOF



  4.0.0

  com.bicosyes # grupo al cual pertenece el proyecto

  HolaMundo # el nombre

  1 # versión del componente

$ mvn install # install!, compila y genera el .jar

$ java -cp target/HolaMundo-1.jar com.bicosyes.hola.Hola

¡Hola mundo!

Pues vaya lata tener que hacer todo eso para un puñetero Hola mundo, ¿no?. Pues si, como nos gusta complicamos la vida a veces... Si no fuese porque además, maven, nos permite ejecutar test JUnit, recopilar informes de los test ejecutados, pasar pruebas de checkstyle, generar javadocs en diferentes formatos, crear packages jar/war/ear/ejb, subirlo a servidores remotos y cosas por el estilo que desconoceré. Además de todo esto, me he dejado su principal característica para el final, gestión de dependencias (al más puro estilo apt-get). Se usan repositorios de librerías (ésta es la principal), en el pom.xml se indicará qué librerías son usadas en el proyecto y qué versiones de las mismas (por ejemplo log4j versión 1.2.14). Indicando eso, al intentar realizar el proceso de compilación, maven las descargará, y si éstas, a su vez, dependen de otras librerías, hará lo necesario para que sus dependencias sean resueltas. Ahora ya todo esto del tal maven suena mejor, ¿no?. Sabes que si.

Uno de los principales fuertes de maven (desde mi punto de vista) es su facilidad y su modularidad (propio de la fundación Apache) que se traduce en una gran facilidad para escribir plugins y usarlos. Tenemos desde plugins de reporting hasta plugins para ejecutar tareas Ant (si, el de antes), pasando por deployment en servidores tomcat, por citar algunos que conozco de primera mano.

¿Alguna parte negativa? Hombre pues salvo el Monstruo de Espagueti Volador, nada es perfecto. El mayor punto negativo está en que, lógicamente, no vamos a tener todo en el repositorio y resignarse a usar la versión 'X' no es una opción, por lo que no es muy raro el tener que instalar en un repositorio propio controlado las versiones de las librerías que necesitemos (con todo lo que esto conlleva... piensa en las dependencias, por ejemplo...). Además el plugin para ejecutar test JUnit funciona dependiendo de la posición de los planetas, he debugeado pero sin mucho éxito, lo tengo como tarea pendiente (de baja prioridad por ahora).

Algunos enlaces para empezar

En Java |

5 Comentarios »

RSS feed para los comentarios de esta entrada.

[...] algún método para empaquetar y distribuir dicha aplicación. La mejor alternativa actualmente es Maven, como expliqué en un post anterior. Maven se integra perfectamente cuando desarrollas una [...]

Pingback por Bicosyes - since evermore… » Blog Archive » Simple Google Web Toolkit plugin for Maven2 — 2 Julio, 2007 @ 0:46 #
Hemos pasado la semana pasada convirtiendo un porrón de proyectos para usar Maven… una de esas cosas que nunca encuentras el momento de meterte a usar y cuando empiezas piensas porqué has tardado tanto…….. de todas formas, los de Apache son lo peor como documentadores, no es por nada.

Comentario por Lek — 5 Julio, 2007 @ 18:55 #
Te doy toda la razón en eso, Apache (por mi limitada experiencia) suele hacer la documentación mínima, mínima; pero también hay que decir que suele ser todo con una arquitectura muy simple por lo que se contrarresta (lo cual no implica no darse unos pocos quebraderos de cabeza iniciales). El caso contrario diría que es Eclipse y sus proyectos varios, documentación tienes a patadas, pero la arquitectura que montan es super, super J2EE, que ahora vas y la entiendes, aunque una vez pasada la curva (más bien pendiente parriba y con piolet de ese) de aprendizaje inicial, fiesta xD

Comentario por blaxter — 5 Julio, 2007 @ 20:53 #
Hola,

perdón si es demasiado tarde para escribir un comentario! pero estoy buscando información sobre maven, y Sant Google me mandó a tu página…
Estoy creando un archivo war con maven y eclipse para hacer el deploy en tomcat, tengo todo el proyecto en la siguiente ruta /home/victor/Escritorio/myproject, dentro de este directorio tengo otro que es src/main/webapp/WEB-INF/ y aquí dentro algunos archivos de configuración. Todo compila y funciona bien en tomcat, el problema fue al intentar mover ese directorio myproject a uno donde están mis proyectos (este directorio en el Escritorio era solo para probar). La aplicación en Tomcat dejó de funcionar y la razón es que el war generado está consultando los archivos de configuración de /home/victor/Escritorio/myproject/src/main/webapp/WEB-INF y no del directorio donde se hace el deploy de ese archivo dentro del WEB-INF.
La verdad es que es un poco frustrante. He consultado información sobre “absolute path”, “relative path” y no consigo encontrar nada. Si me pudieses ayudar te estaría muy agradecido.

De todas formas gracias!!

Comentario por Victor — 16 Junio, 2008 @ 18:04 #
@Victor, mucho sentido no tiene. ¿No será por alguna ruta absoluta que exista en tu código?, Si puedes pegar tu pom.xml en algún lado para verlo (pastebin.com por ejemplo), pero no creo que sea problema de maven sino de algún recurso que intentas abrir con ruta completa.

Comentario por blaxter — 16 Junio, 2008 @ 21:58 #