2008-10-29 12 views

Respuesta

41

ClassPathHelper es un buen comienzo.

Identifica automáticamente huérfanos y mucho más.

La única limitación son las dependencias que no están definidas en las clases, p. en los archivos de configuración del marco de inyección de dependencia.

También tiene otras opciones/complementos, tales como:

  • workingfrog "Relief", que se basa en la capacidad de tratar con objetos reales mediante el examen de su forma, tamaño o el lugar relativo en el espacio que da una "física" ver los paquetes, tipos y campos de Java, y sus relaciones, haciéndolos más fáciles de manejar.
  • Unnecessary Code Detector: una herramienta PlugIn de eclipse para encontrar el código de Java público innecesario (muerto).
+0

pregunta similar con una respuesta diferente http://stackoverflow.com/questions/1012298/how-can-i-identify-innecesary-jars-included-in-my-project –

+0

el primer enlace @VonC mencionado parece movido/roto –

+0

@manocha_ak sí, el proyecto Relief sobre workingfrog ya no existe. He restaurado un enlace de web.archive.org a ese sitio. – VonC

26

UCDetector no ayuda para esto: No funciona en los frascos. Y para classpathHelper, no he podido encontrar una manera sencilla de listar los JAR huérfanos (por cierto, si alguien tiene un tutorial para esto, estoy interesado).

Por lo tanto, si también está usando Maven como yo, averigüe this great Maven plugin, y me gustaría compartir esta solución con usted. Sólo tipo:

mvn dependency:analyze 

Y al instante se obtendrá una lista de archivos JAR no utilizados en sus dependencias. ¡Muy útil!

+2

Muchas gracias por la sugerencia de 'mvn: analizar'. Hace el trabajo de una manera muy fácil. En mi opinión, es mucho más simple que usar una de las otras herramientas mencionadas. –

+1

Tenga en cuenta que 'mvn dependency: analyze' podría dar falsos negativos: por ejemplo, no puede descubrir una dependencia si la clase dependiente se instancia a través de' Class.newInstance() 'o' Constructor.newInstance() 'y manipulada a través de una interfaz. Este es un escenario común en proyectos que usan un marco de inyección de dependencia como Spring. Sin embargo, es un buen punto de partida. – Pino

0

Sé que esta es una antigua, pero si alguien más se topa con esto, Eclipse lo hace por sí mismo.

Vaya a Project propiedades-> Código de Java Style-> Limpiar Seleccione el Eclipse [Built-in] y se hace lo siguiente:

  • cambio no estática accede a miembros estáticos mediante la que se declara el tipo
  • Cambio indirecta accede a miembros estáticos para dirigir accesos (accede a través de subtipos)
  • Retire las importaciones no utilizados
  • Añadir faltante anotaciones '@ Override'
  • Añadir
  • falta anotaciones '@ Override' a las implementaciones de interfaz métodos
  • Añadir faltante anotaciones '@deprecated'
  • Retirar los moldes innecesarios
  • eliminar innecesarias etiquetas '$ NO $ NLS'
+0

Esto no es exactamente lo que estaba preguntando. Quería encontrar qué jarras están incluidas en el proyecto que no son necesarias. La limpieza hace un trabajo diferente (pero aún útil). ¡Aclamaciones! – RodeoClown

5

he encontrado una herramienta muy rápido e interesante para archivar este objetivo:

http://tattletale.jboss.org/

Simplemente descomprima el programa y ejecutar:

java -Xmx512m -jar tattletale.jar ~/myjavaproject/mydistribution output 

Esto generará un informe muy impresionante, con diferentes puntos (texto de su sitio):

  • Identificar las dependencias entre los archivos JAR
  • Encuentra falta clases de classpath
  • Detectar si una clase/paquete está ubicado en varios archivos JAR
  • Localizar si el mismo archivo JAR se encuentra en varias ubicaciones
  • Con una lista de lo que requiere cada archivo JAR y proporciona
  • Verificar la serialVersionUID de una clase
  • Encuentra archivos JAR similares que tienen diferentes números de versión
  • archivos JAR
  • encontrar sin un número de versión
  • Encuentra archivos JAR utilizados
  • Identificar sellados/archivos JAR firmados
  • Localizar una clase en un archivo JAR
  • Get el estado de su proyecto OSGi
  • Retirar negro uso de la API cotizada
  • y generar los mismos informes para su .WAR y archivos .EAR
Cuestiones relacionadas