Más problemas con Maven

Entre ayer y hoy me he dedicado a arreglar un poco los pom.xml de algunos proyectos. En concreto, de un proyecto que tiene como 10 subproyectos debajo. La idea, aprovechando la herencia de proyectos en maven, es quitar lo más posible las cosas que están repetidas en los pom.xml de los subproyectos y ponerlo en el proyecto principal.

También intenté arreglar el tema para que generara un sitio web adecuado, con un montón de informes: cobertura, jxr, métricas pmd, javadoc, etc. Como el CruiseControl está en el mismo sitio que el servidor web, la idea es que el mismo CruiseControl generara el sitio web con mvn site. Puesto que no necesito hacer un mvn site:deploy en condiciones para "subir" el sitio web al servidor web, me planteé la opción de hacer un mvn site:stage, que simplemente genera el sitio en el directorio local que se le indique. Dicho directorio, por supuesto, sería el público del servidor Apache.

mvn site:stage -DstagingDirectory=c:/sitio_web/documentacion_proyecto

Pues nuevamente problemas. Parece que con site:stage algunos plugins no funcionan bien en proyectos con subproyectos. En concreto el jxr, cobertura, etc. Dicen ahí que está corregido para jxr, pero a mi me sigue fallando. Supongo que tendré que jugar con las versiones para asegurarme que cojo la última….

Esta entrada fue publicada en maven. Guarda el enlace permanente.

4 respuestas a Más problemas con Maven

  1. Blaxter dijo:

    ¿Qué diferencia hay entre un «subproyecto» y una dependencia?

  2. Chuidiang dijo:

    Hola:

    No se si «subproyecto» es la palabra correcta, quizás sea «módulo». Tu creas un proyecto maven y en el pom.xml le cambias el packaging por «pom».
    Luego, dentro del directorio de ese proyecto, puedes crear otros proyectos maven. Cada uno de ellos quedará en la estructura de directorio debajo del proyecto principal

    PRINCIPAL/pom.xml
    PRINCIPAL/src
    PRINCIPAL/SUBPROYECTO1/pom.xml
    PRINCIPAL/SUBPROYECTO1/src
    PRINCIPAL/SUBPROYECTO2/pom.xml
    PRINCIPAL/SUBPROYECTO2/src

    De esta forma, los comandos en el directorio PROYECTO se ejecutan en todos los subproyectos automáticamente -mvn install, mvn clean, etc-

    Además, las dependencias, plugins y otras cosas que pongas en el pom.xml del principal, las «heredan» los subproyectos, sin necesidad de poner nada en sus pom.xml

    Si haces que un subproyecto dependa de otro, maven lo tiene en cuenta a la hora de compilar, para hacerlo en orden.

    Se bueno.

  3. Blaxter dijo:

    Interesante, no conocía esa posibilidad de maven, gracias!

    Pero si un «subproyecto», por definición, se puede digamos compilar y testear de forma independiente del principal, ¿no es mejor tratarlo de forma independiente y separada? Alguien se puede dedicar al SUBPROYECTO1, por ejemplo, y no saber nada o saber lo mínimo de «PRINCIPAL», no?

    La ventaja que le veo es que si uno mismo está desarrollando tanto «PRINCIPAL» como varios «SUBPROYECTO_x» puede compilar y tal con un solo comando todo, sin tener que ir uno por uno. Pero en ese caso habría que preguntarse si de verdad son varios subproyectos y no uno solo.

  4. Chuidiang dijo:

    Hola:

    El que trabaja en un subproyecto tiene que tener sacado todo de CVS/subversion, ya que el pom.xml del subproyecto hace referencia y hereda del pom.xml del proyecto padre y debe tenerlo accesible.

    Sin embargo, el del subproyecto puede trabajar en su subproyecto de forma indpendiente, compilando sólo su subproyecto -siempre que no tenga dependencias de los otros subproyectos- y generando sus propios jar.

    Nosotros, por ejemplo, si tenemos un proyecto con cliente y servidor, solemos hacer tres subproyectos, uno para el cliente, otro para el servidor y otro «comun» para las clases que comparten ambos. De esta forma, el cliente lleva sus dos jar -cliente.jar y comun.jar- con solo lo que necesita, el servidor sus dos jar y como bien dices, podemos compilar, generar versiones y documentaciones de un solo golpe con el pom.xml del padre. -salvo como comento el post, que los plugins no vayan bien del todo con estas estructuras 😉 –

    Además, esta estructura tiene la ventaja de que en un momento dado puedes poner etiquetas o ramas de CVS/subversion al proyecto entero de golpe, haciéndolo desde el proyecto padre.

    La pega es que desde el proyecto padre igual no compila nada si uno de los subproyectos falla.

    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.