Maventuras

Los que me conozcan sabrán que éste es un momento de derrota. Tras casi 9 años participando en proyectos de desarrollo Java, hoy he commitado a Subversion un pom.xml.

La versión larga: voy a usar Maven profesionalmente.

¿Qué es Maven, a todo esto? (los no informáticos, ya deberíais haber apagado hace tres párrafos).

Maven es el estándar de facto para compilar (en moderno, hacer build-management) proyectos Java. Existe Ant (y otras cosas más modernas de las que hablaré más tarde), pero Ant es make, es una fantástica herramienta que puede hacer de todo, pero que por defecto, hace muy poco y, especialmente, no resuelve dos de las mayores pérdidas de tiempo en desarrollo Java:

  • Gestión de dependencias de terceros. Quieres usar Hibernate. Hibernate tiene como unas 15 dependencias directas, y algunas de esas dependencias tienen otras dependencias… resultado final, un ratito muy divertido descargando y colocando jars. Y, sobre todo, unas enormes ganas de actualizarse a versiones nuevas…
  • Dependencias entre proyectos. Uno quiere ser bueno y reusar código y modularizar. Poner las clases de utilidad que uno escribe siempre en un módulo que usen todos los proyectos. Hacer librerías de utilidad temáticas. Partir proyectos gordos en módulos separados. Pues bien, hacer un montaje que haga que el proyecto se pueda compilar automáticamente [pongamos con Ant] *y* que se integre propiamente en tu entorno [pongamos Eclipse], no es nada trivial. Queremos que al modificar una clase en un subproyecto, nos la cojan los proyectos de lo que depende. Esto, de hecho, es muy facilito de hacer en Eclipse… pero si quieres tener builds automáticos (pongamos, para hacer integración continua o barbaridades semejantes)… se complica el tema.

Los primeros en solucionar esto, fueron los sres. de Maven, con dos elementos:

  • Un sistema para describir proyectos *declarativo* (Ant es imperativo), que contempla especificar dependencias
  • Un repositorio de librerías Java que contiene todas las librerías relevantes, con sus dependencias especificadas

Con esto, yo puedo declarar que mi proyecto depende de Hibernate y Maven se descargará automágicamente todos los jars necesarios y los meterá en mi proyecto.  Esto ya sería suficiente, pero Maven ofrece más cosas:

  • Arquetipos.  Son una especie de plantillas de proyectos que te permiten crear proyectos típicos fácilmente (Eclipse ofrece algo similar, claro, pero Maven tiene más). Estos reducen, junto a la resolución de dependencias, permiten reducir bastante el coste de montar el esqueleto de un proyecto (nota: ¿más de lo que cuesta hacer funcionar Maven? No.). Estos arquetipos suelen estar bastante bien pensados (i.e. un arquetipo de proyecto web normalmente te generará un .war automáticamente, etc.).
  • Plugins. Todos esos programitas de unit testing, cobertura, análisis estático, etc. se ven traducidos en un plugin de Maven, que con añadirlo al descriptor del proyecto, ya se encarga de hacerlos funcionar casi automáticamente. Uno de estos plugins, por ejemplo, es el que te genera una mini-web de proyecto con documentación, javadocs, descargas, etc. que habréis visto mil veces si habéis visto webs de proyectos Java.

Yo hasta ahora había evitado usar Maven. La primera vez, porque estaban en un momento de transición (de Maven 1 a 2, si no recuerdo mal), había poca documentación, la integración con Eclipse no parecía muy boyante y, por qué no decirlo, bastante NIH. Acabé montando un sistema faraónico basado en Ant que si bien funcionaba como a mi me gustaba, era un poco pesado. Las veces siguientes, acabé reinventando mi pirámide, puliéndola a cada paso, pero haciéndola más complicada y aún no perfecta.

Y hasta hoy hemos llegado.  Se plantea la necesidad de compilar proyectos complejos. La diferencia esta vez es que hay menos libertad inventar cosas y poca voluntad de imponer el sistema a otros. Hora de jugar con Maven.

El primer descubrimiento, parece que hay plugin de Eclipse como Dios manda. Como siempre, hay un inconveniente. Si queremos integración con sistemas de control de versiones, tenemos que instalar los extras, y hay una pequeña nota en la web que dice:

M2Eclipse extensions are available from separate “extras” update site, see Installing m2eclipse for more details. Not all extensions are compatible with the latest M2Eclipse version.

Esto, lógicamente, hace que nos rompamos la cabeza hasta el infinito intentando instalar la compatibilidad con Subversive hasta leer este párrafo. La solución, instalar la versión 0.10.

Hasta ahora, poco más. El descubrimiento es que la manera Maven de gestionar multiproyectos pasa por tener un repositorio propio, cuando opino que no sería estrictamente necesario (al menos en mi caso particular), así que probablemente tendremos que añadir al coste de aprendizaje y montaje de Maven el montar un repositorio (los hay desde muy simples- una carpeta compartida, a auténticos mastodontes).

Para el futuro:

  • Ver si acierto pensando que el repositorio de Maven público es bastante caótico y problemático. Existe un repositorio de Maven de Springsource que tiene buena pinta, pero… ¿estará mucho mejor organizado? Probablemente, sí. ¿Estará todo lo que necesito allí? Probablemente no. ¿Será problemático mezclar el repositorio público y el de Spring? Seguramente.
  • Ver si la cosa funcionará como debe o si requerirá de cuidados.

5 thoughts on “Maventuras

  1. De tot això se’n diu sentit comú. Només et resta utilitzar Scrum per ser complet.

    Per cert, t’has de mirar el repositori públic de Maven des de l’òptica Google, és a dir, no importa com estigui estructurat si no que trobi les coses fàcilment i amb rapidesa. En el cas de Maven, simplement indicant el groupid, l’artifactid i la versió.

    Ja et passaré una llista dels meus plugins preferits.

  2. Sentido común es seguir el estilo Armando…

    No sé yo, no está claro que se ahorre trabajo, el tiempo dirá cuánto tiempo tendré que dedicarle al sr. Maven.

    A lo segundo, no me importa tanto si las cosas están bien clasificadas o no, sino si son consistentes y las dependencias están puestas correctamente. ¿Hay artefactos duplicados y eso puede causar confusión? ¿hay artefactos que contienen cosas que no deberían? etc. Si los de SpringSource han hecho su repositorio… sospecho que por algo será (después de todo, Spring es corregir todo lo que hay chapucero en Java SE y EE).

  3. Sentido común es utilizar herramientas que te permitan aumentar la productividad, y Maven lo hace. Metodologías ágiles como Scrum, también.

  4. Con un número limitado de proyectos también y si no vas a variar las dependencias mucho…?

    Entregas rápidas y continuas es de mi agrado (y de hecho, lo vamos a hacer), sea Scrum, sea Agile, sea XP…

  5. Pingback: Git, gitosis, gradle « El blog es mío…

Deja un comentario

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