Comment supprimer (en toute sécurité) les dépendances Maven inutiles dans Eclipse?

Je travaille sur un projet Java dans Eclipse, utilisant Maven pour créer et gérer des dépendances. Le projet est réparti sur 5 projets Eclipse, l’un d’eux étant le POM parent. Je travaille sur une implémentation de serveur basée sur un serveur beaucoup plus compliqué qu’une autre équipe a implémenté. J’ai donc basé mon travail sur le code préexistant et les fichiers POM, et j’ai maintenant de nombreuses dépendances inutiles dans les POM dans ces projets Eclipse.

Relativement parlant, je suis un débutant Maven, mais je connais cette commande:

mvn dependency:analyze

Lorsque j’exécute cette commande à l’aide du plug-in Eclipse Maven, j’obtiens une longue liste de “dépendances déclarées inutilisées”, mais lorsque j’essaie d’en supprimer quelques-unes, mon programme s’interrompt, parfois de manière mystérieuse.

Existe-t-il une méthode généralement acceptée et conforme aux meilleures pratiques pour traiter ce problème? Ou suis-je résigné à supprimer ces dépendances (probablement) inutilisées une à une, en veillant à ce que rien ne soit cassé après la suppression de chacune d’entre elles?

Vous pouvez essayer d’exécuter votre code avec l’ -verbose:class java -verbose:class activée. Cela générera une sortie vous indiquant où (quel fichier jar) chaque classe est chargée. (Remarque: sur les JRE Sun, cela est écrit en sortie standard. Je pense que sur les JRE IBM, il est écrit en erreur standard.) Voici un exemple de sortie:

 [Loaded junit.framework.AssertionFailedError from file:/D:/Documents%20and%20Settings/mike/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar] [Loaded junit.framework.ComparisonFailure from file:/D:/Documents%20and%20Settings/mike/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar] [Loaded org.jmock.core.SelfDescribing from file:/D:/Documents%20and%20Settings/mike/.m2/repository/jmock/jmock/1.2.0/jmock-1.2.0.jar] [Loaded org.apache.log4j.spi.Configurator from file:/D:/Documents%20and%20Settings/mike/.m2/repository/log4j/log4j/1.2.9/log4j-1.2.9.jar] [Loaded org.apache.log4j.xml.DOMConfigurator from file:/D:/Documents%20and%20Settings/mike/.m2/repository/log4j/log4j/1.2.9/log4j-1.2.9.jar]

Tant que vous parcourez la majeure partie de la logique de votre programme (afin que les classes requirejses soient chargées), vous pouvez sans risque supposer que tous les fichiers jars non mentionnés dans la sortie verbose: class peuvent être supprimés en tant que dépendance maven.

Vous pouvez également effectuer une recherche et un remplacement sur la sortie verbose: class, en le transformant par exemple en csv, puis en l’introduisant dans un tableur pour sortinger / regrouper les fichiers jar.

Encore un peu d’effort manuel, mais au moins cela vous donnerait un sharepoint départ!

Je ne sais pas s’il existe des meilleures pratiques généralement acceptées dans ce domaine, étant donné que tout, de l’introspection aux services, pourrait se rompre au moment de l’exécution. Les tests unitaires pourraient vous aider, mais si vous n’avez pas une bonne couverture, ils pourraient vous donner un faux sentiment de sécurité. Vous devrez toujours vérifier avec des tests de fonction (espérons-le automatisés) après avoir supprimé chaque paquet.