plugin from exclude example dependency compiler java maven-2 maven

java - from - maven-dependency-plugin example



ResoluciĆ³n de dependencia Maven(conflictiva) (5)

Esto no es fundamentalmente un problema de expertos, sino un problema de Java. Si el Proyecto B y el Proyecto C necesitan dos versiones incompatibles del proyecto D, entonces no puede usarlos en el Proyecto A.

La forma Maven de resolver conflictos como estos es desafortunadamente, como ya sabrá, para elegir cuáles excluir.

Usar la mvn dependency:analyze y la mvn dependency:tree ayuda a encontrar los conflictos que tienes.

Digamos que tengo cuatro proyectos:

  • Proyecto A (tiene una dependencia en B y D)
  • Proyecto B (tiene una dependencia en D)
  • Proyecto C (tiene una dependencia en D)
  • Proyecto D

En este escenario, si ejecuto el proyecto A, Maven resolverá correctamente la dependencia a D. Si entiendo esto correctamente, Maven siempre toma la dependencia con la ruta más corta. Como D es una dependencia directa de A, se usará en lugar de D, que se especifica en B.

Pero ahora asuma esta estructura:

  • Proyecto A (tiene una dependencia en B y C)
  • Proyecto B (tiene una dependencia en D)
  • Proyecto C (tiene una dependencia en D)
  • Proyecto D

En este caso, las rutas para resolver D tienen la misma profundidad. Lo que sucede es que Maven tendrá un conflicto. Sé que es posible decirle a Maven que debe excluir las dependencias. Pero mi pregunta es cómo abordar ese tipo de problemas. Quiero decir en una aplicación del mundo real que tienes muchas dependencias y posiblemente también muchos conflictos.

¿La mejor solución de práctica es realmente excluir cosas o hay otras posibles soluciones para esto? Me resulta muy difícil tratar cuando de repente recibo una excepción ClassNotFound porque algunas versiones han cambiado, lo que causó que Maven tomara una dependencia diferente. Por el hecho de que saber este hecho hace que sea un poco más fácil adivinar que el problema es un conflicto de dependencia.

Estoy usando maven 2.1-SNAPSHOT.


Maven puede manejar ambas situaciones sin ningún conflicto. Los conflictos existirán cuando se requieran dos versiones de una dependencia transitiva. La ClassNotFoundException que describe los resultados de la aplicación (o una dependencia) que intenta utilizar una clase no disponible en la versión de la dependencia conflictiva que realmente se usa. Hay varias formas de solucionar el problema.

  1. Actualice las versiones de las bibliotecas que está utilizando que dependen de la dependencia en conflicto, de modo que todas dependan de la misma versión de versión de esa dependencia
  2. Declare la dependencia en conflicto como una dependencia directa de su proyecto con la versión que desea incluir (en el ejemplo, el que tiene la clase faltante incluida)
  3. Especifique qué versión de la dependencia en conflicto deben usar las dependencias transitivas, a través de la sección <dependencyManagement> del POM
  4. Excluya explícitamente las versiones no deseadas de la dependencia en conflicto para que no se incluyan en las dependencias que dependen de ellas mediante una <exclusion>

Puede enforce dependencias consistentes en todo el proyecto con la regla Dependencia de convergencia .

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-enforcer-plugin</artifactId> <version>1.3.1</version> <executions> <execution> <id>enforce</id> <configuration> <rules> <DependencyConvergence/> </rules> </configuration> <goals> <goal>enforce</goal> </goals> </execution> </executions> </plugin>


Una posible estrategia es especificar para el proyecto principal, qué versión de D usar (la última fg). Sin embargo, si la biblioteca D no es compatible con versiones anteriores, tiene un problema según lo establecido por kukudas: es imposible usar ambas bibliotecas en su proyecto.

En tal situación, puede ser necesario utilizar B o C en una versión anterior, de modo que ambos dependan de las versiones compatibles de D.


La forma más fácil de resolver situaciones como esta es incluir una sección <dependencyManagement> en el pom raíz de su proyecto, donde se especifica qué versión de qué biblioteca se utilizará.

EDITAR:

<dependencyManagement> <dependencies> <dependency> <groupId>foo</groupId> <artifactId>bar</artifactId> <version>1.2.3</version> </dependency> </dependencies> </dependencyManagement>

Ahora, independientemente de la versión de biblioteca foo: bar solicitada por una dependencia, la versión 1.2.3 siempre se usará para este proyecto y para todos los subproyectos.

Referencia: