sonar java
8.8.0.37665
Dieses SonarSource -Projekt ist ein Codeanalysator für Java -Projekte, mit denen Entwickler sauberen Code produzieren können. Informationen zur Analyse der Java -Funktionen finden Sie hier.
Um Feedback zu geben (eine Funktion anfordern, einen Fehler melden usw.) verwenden Sie das Sonar Community Forum. Bitte vergessen Sie nicht, die Sprache (Java!), Plugin -Version und Sonarqube -Version anzugeben.
Wenn Sie eine Frage haben, wie Sie Plugin verwenden (und die Dokumente helfen Ihnen nicht), empfehlen wir Ihnen auch, das Community -Forum zu verwenden.
Um eine neue Funktion anzufordern, erstellen Sie bitte einen neuen Thread im Sonarqube Community Forum. Selbst wenn Sie vorhaben, es selbst zu implementieren und an die Community zurückzugeben, starten Sie zuerst einen neuen Thread, um sicherzustellen, dass wir ihn verwenden können.
Um einen Beitrag einzureichen, erstellen Sie eine Pull -Anfrage für dieses Repository. Bitte stellen Sie sicher, dass Sie unserem Codestil folgen und alle Tests bestehen (alle Schecks müssen grün sein).
Wenn Sie eine Idee für eine Regel haben, sich jedoch nicht sicher sind, ob jeder sie benötigt, können Sie eine benutzerdefinierte Regel nur für Sie implementieren. Beachten Sie, dass wir, um Ihnen zu helfen, dringend empfehlen, zunächst das Tutorial für benutzerdefinierte Regeln 101 zu befolgen, bevor wir direkt in die Implementierung von Regeln von Grund auf neu eingehen.
Möchten Sie ganztägig an diesem Projekt arbeiten? Wir stellen ein! Schauen Sie sich https://www.sonarsource.com/hiring an
Um Tests lokal auszuführen, folgen Sie diesen Anweisungen.
Sie benötigen Java 22 um das Projekt zu bauen, und Java 17 Führen Sie die Integrationstests (ITS) aus.
Java 17 kann verwendet werden, um alle Module zu erstellen und zu testen, außer unter java-checks-test-sources , für Java 22 erforderlich ist.Java 22 kann verwendet werden, um alle Module zu erstellen und zu testen, außer unter its , die aufgrund der SQ -Inkompatibilität Java 17 benötigt.Führen Sie diesen Befehl aus dem Stammverzeichnis des Projekts aus, um das Plugin zu erstellen und seine Unit -Tests auszuführen:
mvn clean install
Durch die Ausführung von Unit -Tests innerhalb der IDE kann aufgrund der Art und Weise, wie das Projekt mit Maven erstellt wird, in einigen Problemen anfallen. Wenn Sie so etwas sehen:
java.lang.SecurityException: class ... signer information does not match signer information of other classes in the same package
Versuchen Sie, die Maven -Natur des "JDT" -Moduls zu entfernen.
Um Integrationstests auszuführen, müssen Sie eine Eigenschaftendatei wie die unten gezeigte Erstellung erstellen und die URL auf ihren Standort in einer Umgebungsvariablen mit dem Namen ORCHESTRATOR_CONFIG_URL festlegen.
# version of SonarQube Server
sonar.runtimeVersion=LATEST_RELEASE
orchestrator.updateCenterUrl=http://update.sonarsource.org/update-center-dev.properties
# The location of the Maven local repository is not automatically guessed. It can also be set with the env variable MAVEN_LOCAL_REPOSITORY.
maven.localRepository=/home/myName/.m2/repository
Mit zum Beispiel wird die Variable ORCHESTRATOR_CONFIG_URL als:
export ORCHESTRATOR_CONFIG_URL=file:///home/user/workspace/orchestrator.properties
Stellen Sie vor dem Ausführen des ITS sicher, dass Ihre Umgebungsvariable von Maven_Home festgelegt ist.
Der "Sanity -Test" ist ein Test, bei dem alle Schecks gegen alle Testquelldateien ausgeführt werden, ohne das Ergebnis der Analyse zu berücksichtigen. Es prüft, dass Regeln in einer Datei in unseren Testquellen nicht abstürzen. Standardmäßig ist dieser Test vom Build ausgeschlossen. Um es zu starten:
mvn clean install -P sanity
Der "Plugin -Test" ist eine Integrationstestsuite, die Plugin -Funktionen wie metrische Berechnung, Abdeckung usw. überprüft, um es zu starten:
mvn clean install -Pit-plugin -DcommunityEditionTestsOnly=true
Hinweis für interne Mitwirkende: Um auch die Tests auszuführen, die von der Sonarqube Enterprise Edition abhängen, verwenden Sie:
mvn clean install -Pit-plugin
Der "Regierungstest" ist eine Integrationstestsuite, die die Analyse einer großen Codebasis startet, die vom Plugin in Berichtsdateien erstellten Probleme speichert und diese Ergebnisse dann mit den erwarteten Problemen vergleicht (gespeichert als JSON -Dateien).
Um den Test durchzuführen, stellen Sie zunächst sicher, dass die Submodules ausprobiert werden:
git submodule update --init --recursive
Stellen Sie dann sicher, dass die Umgebungsvariable JAVA_HOME für die Ausführung der Regierungstests festgelegt wird und auf Ihre lokale JDK 17 -Installation zeigt. Wenn dies nicht der Fall ist, werden Inkonsistenzen mit den erwarteten Ergebnissen hervorgerufen.
Starten Sie aus dem Ordner its/ruling die herrschenden Tests:
mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
# Alternatively
JAVA_HOME=/my/local/java17/jdk/ mvn clean install -Pit-ruling -DcommunityEditionTestsOnly=true
Hinweis für interne Mitwirkende: Um auch die Tests auszuführen, die von der Sonarqube Enterprise Edition abhängen, verwenden Sie:
mvn clean install -Pit-ruling
Dieser Test bietet Ihnen die Möglichkeit, die von jeder Regel erzeugten Probleme zu untersuchen und sicherzustellen, dass Sie das erwarten. Jede implementierte Regel wirft höchstwahrscheinlich Probleme bei den mehreren Projekten, die wir als Urteilscode -Basis verwenden.
Für eine neu implementierte Regel bedeutet dies, dass ein erstes Build höchstwahrscheinlich fehlschlägt, was durch Unterschiede zwischen den erwarteten Ergebnissen (ohne Werte für die neue Regel) und den neuen Ergebnissen verursacht wird. Sie können diese neuen Probleme untersuchen, indem Sie nach Dateien suchen, die nach Ihrer Regel ( squid-SXXXX.json ) im folgenden Ordner benannt sind:
/path/to/project/sonar-java/its/ruling/target/actual/...
Bei vorhandenen Regeln, die geändert werden, können Sie einige Unterschiede zwischen "tatsächlicher" (aus neuer Analyse) und den erwarteten Ergebnissen erwarten. Überprüfen Sie die angezeigten Änderungen sorgfältig und aktualisieren Sie die erwarteten Ressourcen entsprechend.
Alle json -Dateien enthalten eine Liste von Zeilen, die durch Datei indiziert sind und erklären, wo sich die Probleme einer bestimmten Regel befinden. Wenn/wenn für Sie alles gut aussieht, können Sie die Datei mit den tatsächlichen Problemen kopieren unter:
its/ruling/target/actual/
In das Verzeichnis mit den erwarteten Problemen:
its/ruling/src/test/resources/
Zum Beispiel unter Verwendung des Befehls:
cp its/ruling/target/actual/* its/ruling/src/test/resources/
Die Tests im Autoscan -Modul sollen Unterschiede zwischen den Problemen erkennen, die der Java -Analysator mit und ohne Bytecode finden kann. Das Ziel hier ist es, die potenziellen FPS zu erkennen und zu reparieren und die erwarteten FNs zwischen der automatischen Analyse von Sonarcloud zu überprüfen.
Das Ausführen dieses Tests kann in 2 Schritten unterteilt werden:
Stellen Sie sicher, dass das Modul java-checks-tests-sources Modul zusammengestellt wurde (dh die .klassendateien in java-checks-tests-sources/target/ sind auf dem neuesten Stand).
Im Zweifelsfall gehen Sie mit dem Modul java-checks-tests-sources und rennen Sie:
# Use java 22!
mvn clean compile Um die Tests auszuführen, wechseln Sie in den its/autoscan -Ordner und führen Sie aus:
# cd its/autoscan
# use Java 17!
mvn clean package --batch-mode --errors --show-version
--activate-profiles it-autoscan
-Dsonar.runtimeVersion=LATEST_RELEASE Die während der Testausführung erzeugten Artefakte finden sich in its/autoscan/target/actual . Sie möchten die in den Autoscan-Diff-by-Rules erzeugten Ergebnisse vergleichen
Für detailliertere Informationen können Sie die Unterschiede zwischen den mit Bytecode gefundenen Ergebnissen und ohne Bytecode vergleichen, indem Sie zwei jeweilige Ordner vergleichen:
Abhängig von den gefundenen Ergebnissen müssen Sie möglicherweise die Grundwahrheit aktualisieren. Die erwarteten Ergebnisse sind in SRC/Test/Ressourcen aufgeführt.
Sie können es debuggen, indem Sie -Dmaven.binary=mvnDebug als Option beim Ausführen der Tests hinzufügen. Dies führt dazu, dass der Analysator JVM darauf wartet, dass ein Debugger vor dem Fortsetzung eines Debuggers beigefügt ist.
Copyright 2012-2024 Sonarsource.
Sonarqube Analyzers, die nach dem 29. November 2024 veröffentlicht wurden, einschließlich Patch-Fixes für frühere Versionen, werden unter der Sonar-Quelle-verfügbaren Lizenzversion 1 (SSALV1) veröffentlicht.
Einzelheiten finden Sie in Einzeldateien, die die für jede Datei zutreffende Lizenz angeben. Dateien, die dem SSALV1 unterliegen, werden in ihren Kopfzeilen vermerkt.
