Pros y contras de maven

 Llevamos ya varios años usando maven y nos hemos acostumbrado a él. Recordamos ahora cómo teníamos antes los proyectos y nos asombramos de la mejora conseguida. Sin embargo, no todo es bueno con maven, tiene sus pegas.

Ventajas de maven

Hay principalmente tres grandes cosas que hemos conseguido con maven y sin las que ahora no seríamos capaces de trabajar.

La primera es que ahora todos nuestros proyectos están organizados igual. Esto, por supuesto, puede conseguirse con disciplina y sin necesidad de maven, pero en grupos numerosos de desarrolladores es más fácil de conseguir si la herramienta te obliga a seguir una estructura o al menos, si te obliga a hacer un esfuerzo importante si te quieres salir de esa estructura. Se acabó el  hacer scripts de compilado, el preguntar a otro cuando cambias de proyecto dónde están las cosas, el dejar ficheros o iconos por cualquier lado. Ahora cualquiera puede pasar de un proyecto a otro y sabe manejarse por la estructura sin ningún problema.

La segunda gran ventaja son los jar. Al dejar todos los jar de los proyectos en un repositorio centralizado (usamos nexus) y usar versiones SNAPSHOT de maven, todos tenemos siempre disponibles los últimos jars. Antes era necesario que cada uno compilase los jar que  necesitara o se los pidiera a alguien que los tuviera, o que alguien se acordara de meterlos en el sistema de control de versiones. Eso ya no es necesario, maven/nexus se encarga de que todos tengamos siempre los últimos jars.

Y la tercera gran ventaja es la herramienta de integración continua (Hudson), que todas las noches saca los fuentes del sistema de control de versiones, los compila y pone los jars en nexus. Al ser hudson el encargado de meter los jar en nexus, estos siempre están actualizados y siempre está disponible la última versión para todo el mundo. Y al ser hudson el que compila en un servidor separado, eliminamos por un lado los típicos errores de código que sólo compila en el PC del desarrollador Fulanito porque inadvertidamente ha puesto un path suyo local en algún sitio, o se ha olvidado de meter algo en el sistema de control de versiones. Este Hudson nos sirve además para obtener de él las versiones de instalación tanto para el entorno de producción como para pruebas. Ya no dependemos de que alguien tenga todo lo necesario para generar estas versiones y de que ese alguien esté.

Pegas con maven

Pero no todo son ventajas. La gran y enorme pega de maven es su dependencia de que haya internet o al menos red, para acceder al servidor de Hudson. Los problemas con la red suelen ser relativamente frecuentes: se va el servidor de nexus por el motivo que sea, se cae algún proxy o router, etc, etc. En esos casos, se nos queda un poco parado el tema de compilado. Sí, maven tiene una ejecución off-line, pero no funciona todo lo bien que debiera. Si le falta algo, se empeña en ir a buscarlo a través de la red.

Y esta dependencia de la red se nos hace especialmente grave cuando vamos a instalaciones del cliente en los que no hay internet ni, por supuesto, acceso a nuestro nexus. Si queremos llevarnos un entorno de desarrollo para depurar, corregir algún bug y compilar en las instalaciones del cliente, nos obliga a llevarnos toda una copia de repositorios, o montar el proyecto de forma totalmente independiente de maven. Hay comandos de maven que ayudan a hacer toda esta copia, como dependency:go-offline, pero hay que acordarse de hacerlo.

Es bastante molesto también el tema de plugins de maven. A veces y sin saber el motivo, maven decide que debe actualizar plugins a versiones más modernas. En la mayoría de los casos esto no afecta demasiado, pero a veces si coincide con algún tipo de problema de red o el estar off-line, nos hace imposible compilar.

En fin, desde luego las ventajas compensan con creces los inconvenientes y ni se nos pasa por la cabeza dejar de usar maven, pero a veces algunos problemas misteriosos pueden tenerte de pelea con ellos toda una mañana.

Entradas relacionadas:

6 comentarios en “Pros y contras de maven

  1. Pingback: Tweets that mention Diario de Programación » Blog Archive » Pros y contras de maven -- Topsy.com

  2. Me parece que algunas de las pegas son debido a que no se utiliza maven correctamente. Inicialmente deberías de establecer las versiones de los plugins, de la misma forma que estableces la versión de una dependencia. De esta forma te evitas posibles conflictos con las nuevas versiones de los plugins o cambios en el super pom de maven.

    Respecto a las instalaciones en un cliente, tendrás que preparar las cosas que vas a utilizar en el cliente. ¿Cómo lo hacías sin maven? Otro tema podrían ser las dependencias que no se encuentran en repositorios públicos, pero para ello yo utilizaría un repositorio interno al proyecto(además de tenerlo en nuestro nexus).

  3. Sí, es posible que debamos fijar las dependencias de los plugins y de hecho lo hacemos cuando empiezan a darnos problemas las nuevas versiones que se bajan. Pero el problema como comento no suele ser que la nueva versión de plugin dé problemas, sino más bien de dependencia de la conexión a internet. Por desgracia, es relativamente habitual que nos falle por cualquier motivo la conexión (proxy corporativo con usuario y password, varias redes internas interconectadas, routers, puertas de enlace, etc, etc, etc). Cuando hay uno de estos cortes y maven «se empeña» en que tiene que bajarse algo, no hay manera. En cualquier caso, no es lo habitual, normalmente va todo como la seda. Casualmente, y Murphy es infalible, cuando pasa suele haber un hito importante al día siguiente 😛

    En cuanto a lo del cliente, efectivamente, hagas como lo hagas, tienes que preparar y llevarte todo lo que necesites. Maven te ayuda a ello de alguna manera, pero si quieres seguir usando allí maven off-line, te obliga a llevarte un montón de jars/plugins propios de maven y montar el repositorio local completo, con tus jar y los de maven. Y si no usas maven off-line, tienes que hacerte todos esos scripts de compilado que te habías evitado hacer al usar maven.

    No sé si usas maven con asiduidad en proyectos más o menos grandes. Si es así contesta sinceramente, ¿nunca, nunca os da ningún problema?. Sí, el problema se soluciona y suele ser por un despiste o por algún fallo ajeno a maven (de red, por ejemplo), pero a veces se echa la mañana en tratar de solucionarlo.

    Se bueno.

  4. Pingback: de la red – 20/06/2010 « Tecnologías y su contexto

  5. Es verdad que algunos plugins de Maven dan a veces problemas, pero este problema no es de Maven, sino de los plugins de Maven.
    Por lo general nunca hemos tenido problemas con la red y maven, es rara la vez que no tenemos conexión en la red interna. Solemos utilizar un nexus en nuestra red interna, establecemos las versiones de los plugins siempre.
    He utilizado maven en proyectos de unas 40000 LC, y efectivamente hemos tenido problemas con algunos plugins, incompatibilidad de versiones, pero la mayoría de veces se han solucionado estableciendo las versiones correspondiente.
    Otro problema puede ser cuando una librería es añadida a una lista negra ‘blacklisted’. Este problema me parece grave, pero es muy poco usual.

    Nota: Siempre puedes comentar el POM y evitar el plugin que te dé problemas. xD.

  6. Hola de nuevo.
    Sí, al final siempre acabamos resolviendo el problema de una forma u otra. Como comento, en general estamos encantados con maven y ya no sabríamos trabajar sin él o una herramienta similar.
    Lo del blacklisted si nos ha salido a veces, pero como te comento, siempre lo acabamos solucionando de una forma u otra.
    Se bueno.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.