Composición del proyecto de varios módulos de Maven con respecto a las dependencias que comparten

Question

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

Un proyecto de 8-11 proyectos infantiles, que tiene un artefacto/proyecto principal y un proyecto principal que usa/declara a los otros como módulos.

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

No puedo poner esos fragmentos compartidos "no estrictamente" en el proyecto principal para que otros los hereden. Entonces solo los deps comunes son heredados. Y hay toneladas de dependencias duplicadas. Y solo puedo administrar sus versiones a través del <dependencyManagement>.

Otra opción es tener parent pom que contenga la mayoría de las dependencias, pero los proyectos secundarios heredan incluso aquellos que no necesitan.

Podría tener más de 1 proyecto principal, pero no me parece correcto. También la herencia del proyecto principal podría ser una pesadilla, porque no se sabe qué dependencias necesita el proyecto, si no se documenta/comenta correctamente la definición principal de pom.

Otra forma es crear artefactos pom que sirvan solo como contenedores de dependencia: declaran grupos específicos de dependencias, de modo que los módulos simplemente declaran que esos obtienen dependencias transitivas. Pero bueno, le gustaría implementar y cometer algún tipo de

OneDepArtifact declarar jackrabit, abdera, chemistry

AnotherDepArtifact declarar htmlcleaner, google-api, tika

ThirdDepArtifact declarar spring, httpclient, selenium

Es un gran lío, no estoy seguro de si use <dependencyManagement> correctamente, parece ser solo útil para administrar versiones de dependencia.

Estaba pensando en adaptar el desarrollo de mi aplicación al "diseño de multimodulos maven". Pero si desea crear servicios/beans de primavera, simplemente use varias bibliotecas, en un módulo, no las implemente en un módulo diferente, simplemente porque usan una biblioteca que también usa otro módulo :-)

Answer 1

Maven 3.1 debería resolver este problema introduciendo "mixins". Mientras tanto, parece que puedo conseguir la mayor parte de las características que necesita el uso adecuado de los perfiles, como he descrito en esta entrada del blog:

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

Por favor, hágamelo saber si usted encuentra útil.

Answer 2

Si es principalmente sobre el control de versiones (número) - por qué no especificar sólo la versión de la dependencia como propiedad en el proyecto principal y utilizarlo en los proyectos secundarios, como

padres

<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 de proyecto específicas con números de versión consistentes.

Answer 3

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

Describo una buena estructura de proyecto multi-módulo en this answer. También describe el uso de un agregador y la herencia de cadenas de padres.

Algunas cosas que le ayudarán a mantener las cosas organizadas y sano ...

• Use las convenciones de nomenclatura buena; no solo llame a los proyectos principales parent1 y parent2. Use nombres que describan qué tipo de dependencias y otras cosas configuran, de modo que sea intuitivo que las personas sepan qué usar cuando.
• Utilice la función de lanzamiento/implementación de maven para que estas estén versionadas en su repositorio correctamente y siempre hagan referencia a artefactos de versión fija. No usar SNAPSHOTs es el primer paso para tener construcciones deterministas y reproducibles. Problemas de depuración cuando las cosas cambian sobre la marcha es muy difícil.
• 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 perfiles personalizados. Debe usar maven-dependency-plugin para realizar estas tareas de análisis. Hay comandos como mvn dependency:tree que muestran todas las dependencias de un proyecto y mvn dependency:analyze que muestran las dependencias no utilizadas.

Afortunadamente, con este consejo, la herencia del archivo POM principal no parecerá tan complicada y pesadillesca. ¡Buena suerte!