Composición del proyecto multimódulo Maven con respecto al intercambio de dependencias

Question

Hay algunas preguntas similares, pero nada como esto. ¿Cómo lidias con esta situación (escenario típico)?

Un proyecto de 8-11 proyectos infantiles, que tiene un artefacto/proyecto matriz y un proyecto principal que utiliza/declara en su mayoría a aquellos otros como módulos.

El problema es que todos los proyectos "estrictamente" comparten solo las dependencias comunes, como testng, logging, apache commons and stuff. Pero siempre me gusta 3 de ellos usan 50-60% de los mismos DEPS específicos (Apache-Quemistry, JackRabbit, Abdera, etc.), otros 2-3 de ellos también usan 50-60% de las mismas dependencias pero diferentes dependencias. Y el principal usa muchos de los mismos Deps.

No puedo poner esos Deps compartidos "no estrictamente" en el proyecto matriz para que otros los hereden. Entonces, solo se heredan los Deps comunes. Y hay toneladas de dependencias duplicadas. Y solo puedo administrar sus versiones a través de <dependencyManagement>.

Otra opción es que POM de los padres contenga la mayoría de las dependencias, pero los proyectos infantiles heredan incluso aquellos que no necesitan.

Podría tener más de 1 proyecto de padres, pero no se siente bien. Además, la herencia del proyecto matriz podría ser una pesadilla, porque no sabe qué dependencias necesita el proyecto, si no documenta/comenta la definición de POM de los padres correctamente.

Otra forma es crear artefactos de POM que sirvan solo como contenedores de dependencia: declaran grupos específicos de dependencias, de modo que los módulos simplemente declaran aquellos para obtener dependencias transitivas. Pero bueno, ¿te gustaría implementar y cometer algún tipo de

OneDePartifact declarando jackrabit, abdera, chemistry

Otro Departifact declarando htmlcleaner, google-api, tika

Tercer Departifact declarando spring, httpclient, selenium

Es un gran desastre, no estoy seguro de si uso <dependencyManagement> correctamente, parece ser solo útil para administrar versiones de dependencia.

Estaba pensando en adaptar el desarrollo de mi aplicación a "Maven Multimodule Design". Pero si desea crear servicios de primavera/frijoles, que solo usan varias bibliotecas, en un módulo, no las implementa en diferentes módulos, solo porque usan la biblioteca que otro módulo también usa :-)

Answer 1

Maven 3.1 debería resolver este problema introduciendo "Mixins". Mientras tanto, parece que puedo obtener la mayoría de las características necesarias mediante el uso adecuado de los perfiles, como describí en esta publicación de blog:

http://weblogs.java.net/blog/fabriziogiudici/archive/2011/07/19/maven-pom-composition-means-profiles

Por favor, hágame saber si lo encuentra útil.

Answer 2

Sé que dijiste que podría ser una pesadilla, pero siento firmemente que la herencia entre tus padres es el camino a seguir.

Describo una buena estructura de proyecto multimódulo en esta respuesta. También describe el uso de un agregador y una herencia de cadena principal.

Algunas cosas que te ayudarán a mantener las cosas organizadas y sanas ...

• Use buenas convenciones de nombres; No solo llame a los proyectos de los padres parent1 y parent2. Use nombres que describan qué tipo de dependencias y otras cosas que configuran para que sea intuitivo que las personas sepan cuál usar cuándo.
• Use la función de lanzamiento/implementación de Maven para que estén versionadas en su repositorio correctamente y siempre haga referencia a los artefactos de versión fija. No usar instantáneas es el primer paso para tener compilaciones deterministas y reproducibles. Los problemas de depuración cuando las cosas cambian sobre la marcha son muy difíciles.
• No confíe en un archivo pom.xml para saber qué dependencias necesita su proyecto. Esto lo llevará a evitar la herencia y otras cosas como los perfiles personalizados. Deberías usar el maven-dependencia-plugin Para realizar estas tareas de análisis. Hay comandos como mvn dependency:tree que le muestra todas las dependencias de un proyecto y mvn dependency:analyze que te muestra dependencias no utilizadas.

Con suerte, con este consejo, la herencia de los archivos POM para padres no parecerá tan complicada y de pesadilla. ¡Buena suerte!

Answer 3

Si se trata principalmente del control de la versión (número): ¿por qué no especificar solo la versión de dependencia como propiedad en el proyecto principal y usarla en los proyectos infantiles, como

Padre

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>foo.bar</groupId>
    <artifactId>maven-parent</artifactId>
    <version>0.0.1</version>
    <packaging>pom</packaging>

    <properties>
        <log4j.version>1.2.16</log4j.version>
    </properties>

</project>

Niño

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <artifactId>maven-parent</artifactId>
        <groupId>foo.bar</groupId>
        <version>0.0.1</version>
    </parent>

    <groupId>foo.bar</groupId>
    <artifactId>maven-child</artifactId>
    <version>0.0.1-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>${log4j.version}</version>
        </dependency>
    </dependencies>

</project>

Esta es una solución simple que le permite especificar dependencias específicas del proyecto con números de versión consistentes.