java - que - Composición del proyecto multimodular de Maven con respecto al intercambio de dependencias

maven tutorial español

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 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 de <dependencyManagement> .

Otra opción es que parent pom 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 solo declaren aquellos para obtener dependencias transitivas. Pero, oye, ¿te gustaría implementar y cometer algún tipo de

OneDepArtifact declara jackrabit, abdera, chemistry

htmlcleaner, google-api, tika declarando htmlcleaner, google-api, tika

ThirdDepArtifact declarando spring, httpclient, selenium

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

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

Answer 1

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

Answer 2

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 del 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 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 de varios módulos en esta respuesta . También describe el uso de un agregador y la herencia de encadenamiento de padres.

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

• Use buenas convenciones de nombres; 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 el complemento maven-dependency-plugin para realizar estas tareas de análisis. Hay comandos como mvn dependency:tree que muestra todas las dependencias de un proyecto y mvn dependency:analyze que muestra las dependencias no utilizadas.

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