¿Cómo encontrar dependencias innecesarias en un proyecto múltiple de maven?

Question

Si está desarrollando un proyecto maven de múltiples módulos en evolución, parece inevitable que haya algunas dependencias en los poms que son innecesarias, ya que están incluidas transitoriamente por otras dependencias. Por ejemplo, esto sucede si tienes un módulo A que originalmente incluye C. Más adelante refactorizas y haces que A dependa de un módulo B que a su vez depende de C. Si no eres lo suficientemente cuidadoso, terminarás con B y C en Lista de dependencia de A Pero, por supuesto, no necesitas poner C en el pomo de A, ya que está incluido transitoriamente, de todos modos. ¿Hay alguna herramienta para encontrar tales dependencias innecesarias?

(Estas dependencias en realidad no duelen, pero que podrían oscurecer su estructura de módulo real y tener menos cosas en el POM es generalmente mejor. :-)

Answer 1

Hasta cierto punto se puede utilizar dependency:analyze, pero no es demasiado servicial. También marque JBoss Tattletale.

Hace un tiempo comencé un maven-storyteller-plugin para poder analizar más a fondo los poms, pero el proyecto está muy lejos de la producción/uso público. Puede usar el objetivo storyteller:recount para analizar las dependencias no utilizadas/redundantes.

El problema con toda la historia es: cómo determinar las cosas "sin usar". Lo que es bastante posible de analizar es, por ejemplo, referencias de clase. Pero no funcionará si usa la reflexión, directa o indirectamente.

actualización de noviembre de 2014.

acabo moved my old code of the Storyteller plugin to GitHub. Lo actualizaré y lanzaré a la central para que pueda ser usado por otros.

Answer 2

Cuando se tiene A -> B, B -> C, y luego refactor tal que A -> (B, C). SI es el caso de que Un todavía compila contra B, gracias no quiere simplemente recoger la dependencia debido a que lo reciba de manera transitiva.

Piense en el caso cuando A -> (B-1.0, C-1.0), B-1.0 -> C-1.0. Todo está sincronizado, por lo tanto, para evitar la "duplicación", elimine C de Dependencia de. Luego, actualice A para usar B-2.0 -> C-2.0. Comienza a ver errores porque A quiere clases C-1.0 pero encontró clases C-2.0. Aunque se puede conciliar rápidamente en este escenario, es mucho menos así cuando tienes muchas dependencias.

Usted lo desea fervientemente la información en pom Un 's que dice explícitamente que espera encontrar C-1.0 en la ruta de clase para que pueda entender cuando tiene conflictos dependencia transitiva. Una vez más, Maven hará el trabajo de garantizar que la versión "más cercana" de un contenedor en particular termine en su classpath. Pero cuando las cosas van mal, quiere todos los metadatos de dependencia que puede obtener.

En una nota un poco más práctica, una dependencia no se utiliza cuando puede eliminarlo de su pom y todas sus pruebas de unidad/integración/aceptación aún pasan.;-)

Answer 3

I

usar personalmente el editor de pom M2Eclipse visualmente ver el árbol de dependencias (árbol 2D). Luego le doy un vistazo a mis directorios de entregables (war, ear) lib. Luego, aún en el visor de dependencias M2Eclipse pom, voy a cada tercero y hago clic con el botón derecho en la dependencia que quiero excluir (se agrega automáticamente una exclusión en la dependencia correcta).

No hay reglas de oro, sólo algunos consejos básicos:

una gran cantidad de POM no son correctas: una gran cantidad de bibliotecas 3 ª parte por ahí requieren demasiado dependencias en el compilador por defecto alcance, si todo el mundo con cuidado artesanal su pom, no debe tener tantas dependencias no deseadas.

necesita adivinar por el nombre de las dependencias lo que tendrá que excluir, el mejor ejemplo son los analizadores, transformador, constructor de documentos: xalan, xerces, xalan alfred y co. intente eliminarlos y use el analizador jdk1.6 interno, cosas comunes de Apache, también vale la pena mirar log4j.

mirada también regularmente en la entrega lib si no tienen bibliotecas duplicados con versión diferente (el solucionador de dependencias del experto debe evitar que)

ir de abajo hacia arriba, comience con sus módulos comunes, luego subir hasta el servicio capa, reduciendo las dependencias en cada módulo, no intente iniciarse en módulos ear/war, será demasiado difícil

verifique con frecuencia si el entregable aún está funcionando, ya sea probando o comparando y viejo entregable con el nuevo (especialmente en el directorio web-inf/lib que ha desaparecido con winmerge/beyoncompare)