Eine der leistungsfähigsten Funktionen von Maven ist der Berichtsmechanismus, auch bekannt als Maven Site. Es gibt eine Vielzahl von Berichten, die Ihnen einen Hinweis auf die Qualität Ihres Codes geben können. Wenn Sie sich jedoch überfordern, indem Sie zu viele Berichte hinzufügen oder zulassen, dass die Berichte zu viele Informationen produzieren, werden sie von allen ignoriert und die Berichte werden nutzlos. In diesem Blog werde ich Ihnen mitteilen, welche Berichte wir in meiner aktuellen Aufgabe ausgewählt haben und wie Sie bestimmte Maven-Berichte anpassen können, um die von Ihnen gewünschten Informationen zu erhalten.
Beginnen wir mit der Auflistung der Berichte, die wir ausgewählt haben:
ReportReason
| Surefire Bericht | Ein bisschen offensichtlich, aber trotzdem. Wird für Testergebnisse verwendet. Es ist wichtig zu wissen, ob ein Test fehlschlägt. |
| Cobertura Bericht | Code-Abdeckung. Die Codeabdeckung ist nicht der heilige Gral und sagt nichts über die Qualität Ihrer Tests aus, kann Ihnen aber eine Einschätzung darüber geben, wie viel getestet wird. Als Faustregel gilt, dass Sie mit der Untersuchung beginnen sollten, wenn sie weniger als 70% beträgt. |
| JDepend Bericht | Ich verwende es hauptsächlich, um Zyklen in Ihrem Code zu erkennen. Zyklen erschweren die Wartung des Codes und machen meinen Kollegen Age wütend :-) |
| PMD-Bericht | Statische Code-Analyse wie nicht geschlossene Ressourcen. Dieser Bericht enthält auch die zyklomatische Komplexität, die ein guter Design-Indikator ist. |
| CPD-Bericht | Kopieren-Einfügen-Detektor. Duplizierter Code ist böse. |
| FindBugs Bericht | Statische Code-Analyse. FindBugs ist besser im Auffinden von Threading-Problemen als PMD. |
Anhand dieser Berichte können Sie ein gutes Gefühl für den Code Ihres Projekts bekommen. Konfiguration von Bei Surefire, Cobertura, JDepend und CPD gibt es nicht viel zu konfigurieren, daher werde ich mich auf PMD und FindBugs konzentrieren. PMD. Standardmäßig produziert PMD eine Menge Informationen in seinen Berichten. Erschrecken Sie nicht, wenn Sie standardmäßig mehr als 500 Verstöße pro Maven-Projekt sehen. Das Problem bei dieser Menge an Problemen ist, dass der Bericht selbst ziemlich nutzlos wird. Niemand wird jemals alle 500 Probleme durchgehen und - was noch wichtiger ist - sie alle beheben. Viele dieser Probleme haben mit dem Stil zu tun (Verwendung von Klammern) und sind nicht optimal auf die Leistung abgestimmt. Ich möchte, dass PMD nur die wichtigen Regeln meldet, die bösen Fehlerverursacher wie das Nicht-Schließen von Streams, das Verschlucken von Exceptions, Threading-Probleme usw. Auf der PMD-Website finden Sie eine umfassende Dokumentation darüber, worüber PMD berichten wird. In PMD gibt es Regeln und Regelsätze. Regelsätze sind Gruppen von Regeln und anderen Regelsätzen. Standardmäßig bietet PMD einen Regelsatz, der mit dem Plugin ausgeliefert wird. Um diesen anzupassen, müssen Sie Ihren eigenen Regelsatz erstellen, wie auf der PMD-Website beschrieben. So erstellen Sie Ihre eigene ruleset.xml, die aus anderen Regelsätzen und/oder Regeln besteht: So fügen Sie den kompletten Regelsatz String und StringBuffer zu Ihrer eigenen benutzerdefinierten ruleset.xml hinzu:
Um alle Regeln aus dem Regelsatz String und StringBuffer mit Ausnahme von AvoidDuplicateLiterals und InefficientStringBuffering hinzuzufügen, tun Sie:
Dann konfigurieren Sie Ihren Maven-Bericht wie folgt:
maven-pmd-plugin
2.3
5
${basedir}/src/main/config/custom-pmd-rules.xml
FindBugs FindBugs ist standardmäßig viel weniger ausführlich als PMD. Dennoch kann es über Verletzungen von Fehlern berichten, die uns nicht interessieren, oder über Verletzungen, die uns wichtig sind, nicht berichten. In FindBugs gibt es Bugs und Kategorien, die Bugs enthalten. Auf der FindBugs-Website finden Sie auch eine Liste aller möglichen Fehler, über die das Programm berichten kann. Um einzelne Fehler einzuschließen oder auszuschließen, fügen Sie dies in Ihre include- oder exclude-Datei ein:
Wenn Sie komplette Kategorien ein- oder ausschließen möchten, geben Sie dies in Ihrer Include- oder Exclude-Datei an:
Und um Ihren Bericht zu konfigurieren:
org.codehaus.mojo
findbugs-maven-plugin
1.1.1
true
Standard
${basedir}/src/main/config/findbugs-excludes.xml
Es gibt noch ein Problem. Die obige Konfiguration erfordert, dass ich die Dateien mit den Regeln an alle meine Projekte verteile. Das ist nicht sehr wartungsfreundlich. Stattdessen möchte ich diese Regeln in einer jar-Datei haben, die ich als Maven-Abhängigkeit hinzufügen kann. Leider kann das Maven FindBugs Plugin keine Klassenpfad-URLs als exclude/include-Datei verarbeiten. Wir müssen also einen kleinen Maven-Hack durchführen, indem wir das maven-antrun-plugin verwenden, um die jar-Datei, die beide XMLs enthält, wie folgt in das Zielverzeichnis zu extrahieren:
org.apache.maven.plugins maven-antrun-plugin kompilieren Prozess-Ressourcen laufen com.xebia.blog.example benutzerdefinierte Metriken 1.0
Dann verweisen Sie einfach auf ${project.build.directory}/unjar-custom-metrics" für den Speicherort der PMD-Datei und der FindBugs include- oder exclude-Datei.
Dashboard
Maven 1 bot ein Dashboard, das alle Berichte Ihres Maven-Projekts auf einer einzigen Seite zusammenfasste. Wie in diesem früheren
Verfasst von
Lars Vonk
Unsere Ideen
Weitere Blogs
Contact