2017-08-25 2 views
3

Ausführen von SonarQube 6.4 mit Java-Plugin 4.9.0.9858.Ich habe eine Regel geschrieben, um zu bestätigen, dass Maven-Projekte, die intern entwickelt wurden, eine übergeordnete POM-Datei importieren, die Standardversionsnummern für verschiedene Bibliotheken enthält. Ich habe die Regel im Qualitätsprofil erfolgreich codiert, getestet, implementiert und aktiviert. Wenn ich jedoch einen Scan für ein Maven-Projekt mit diesem Qualitätsprofil durchführe, wird die Regel nicht ausgelöst.SonarQube erkennt keine benutzerdefinierte PomCheck-Regel

Ich kann sehen, Klasse org.sonar.java.xml.XmlAnalyzer entscheidet, welche Regeln für xml-Dateien im Allgemeinen und Pom-Dateien im Besonderen gefeuert werden. Insbesondere wählt XMLAnalyzer alle Regeln aus, die Instanzen von org.sonar.java.xml.maven.PomChecks sind, um sie auf pom.xml-Dateien anzuwenden.

Problem ist, meine benutzerdefinierte Regel eine Instanz der Klasse ist org.sonar.java.xml.maven.PomCheck, wie

import org.sonar.java.xml.maven.PomCheck; 

...snip... 

@Rule(key = "UseParentPOM") 

public class UseParentPOM implements PomCheck { 

...snip... 

Methode genau Dieses „implementiert PomCheck“ folgt, ist wie Java-Plugin wie GroupIdNamingConventionCheck definieren sich als PomChecks Regeln geliefert - und sie sind sind werden während meines Scan-Laufs ausgewählt. Ich habe überprüft, dass ich meine benutzerdefinierten Regeln mit derselben Plug-in-Bibliotheksversion kompiliere, die von der SQ-Installation verwendet wird. Und das Ausführen von Sonar-Scanner-Debugging und Anfügen an den laufenden Prozess zeigt, dass meine UseParentPOM-Regel tatsächlich in der Besucherliste ist, die XMLAnalyzer verwendet, um nach Kandidatenregeln zu suchen. Aber die spezifische Bedingung von "visitor instanceof PomCheck" gibt false zurück. Ergo, meine Regel wird nicht zur Liste der Pom-Regeln hinzugefügt und wird nicht ausgelöst, wenn die pom.xml gescannt wird.

Offensichtlich ist meine Regelklasse nicht das PomCheck, das XMLAnalyzer erwartet, aber was mache ich falsch, um es zu einer Instanz von PomCheck zu machen?

UPDATE

Einige weitere Gräben zeigen, dass die .jar-Datei die Klasse, Java-Frontend-4.9.0.9858.jar Bereitstellung, in sowohl die Basis Sonar-java-plugin-4.9.0.9858.jar und meine custom-java-rules-1.0-SNAPSHOT.jar. Meine Debugging-Läufe zeigen, dass SonarQube anscheinend separate Klassenladeprogramme für jedes Plugin .jar im Verzeichnis extensions startet. So gibt es tatsächlich, soweit es SQ betrifft, 2 'org.sonar.java.xml.maven.PomCheck' Klassen. Daher mein ursprüngliches Problem.

Ich habe daher versucht, Java-Frontend-4.9.0.9858.jar (und damit die PomCheck-Klasse) von meinen benutzerdefinierten Regeln .jar zu entfernen, indem alle Sonar-Abhängigkeiten als < > vorausgesetzt. Meine Hoffnung war, der resultierende SQ-Prozess hätte dann 1 PomCheck-Klasse, um alle zu beherrschen. Das eigentliche Ergebnis ist jedoch, dass SQ nicht gestartet wird, da der Web-Server-Prozess fehlschlägt, wenn versucht wird, meine benutzerdefinierten Regelklassen zu laden, da die Klasse (POMCheck) nicht gefunden werden kann.

Ich erlebe daher ein unlösbares Dilemma - wenn ich PomCheck in meine benutzerdefinierte .jar einfüge, startet SQ gut, erkennt aber meine benutzerdefinierte Regel nicht als "echten" PomCheck. Wenn ich PomCheck nicht in meine benutzerdefinierte .jar-Datei einfüge, wird SQ überhaupt nicht gestartet. So, jetzt bin ich wirklich in einer Zwickmühle - bitte helfen.

WEITERE DETAILS

Re: Nicholas B Wunsch, den Code meiner benutzerdefinierten Regel Registrierung ist wie

folgt
public final class MyRulesList { 

...snip... 

public static List<Class<? extends JavaCheck>> getChecks() { 
    return ImmutableList.<Class<? extends JavaCheck>>builder().addAll(getJavaChecks()).addAll(getJavaTestChecks()).build(); 
} 
public static List<Class<? extends JavaCheck>> getJavaChecks() { 
    return ImmutableList.<Class<? extends JavaCheck>>builder() 
     .add(PackageNaming.class) 
     .add(LoggingLevels.class) 
     .add(UseParentPOM.class) 
     .build(); 
} 
... snip ... 

}

Dieser Code wurde direkt aus dem Schreiben von benutzerdefinierten Java-Regeln kopiert 101 Website.Alle 3 benutzerdefinierten Klassen sind ordnungsgemäß registriert, so weit ich sehen kann - ich kann sie in der Benutzeroberfläche der Webkonsole sehen und sie dort einem Quality Gate hinzufügen. Der einzige Unterschied zwischen den Regeln PackageNaming/LoggingLevels und der Regel UseParentPOM besteht darin, dass UseParentPOM die PomCheck-Schnittstelle und nicht JavaCheck implementiert. Da jedoch die Klasse PomCheck nichts anderes als ein Wrapper um die Klasse JavaCheck ist, schien dies der richtige Weg zu sein, die UseParentPom-Klasse zu registrieren, z. genau wie jeder andere JavaCheck. Aber vielleicht nicht?

+0

Können Sie Ihre Frage mit weiteren Details/Code darüber aktualisieren, wie Ihre Regel [registriert und aktiviert] ist (https://docs.sonarqube.org/display/PLUG/Writing+Custom+Java+Rules+101#WritingCustomJavaRules101- RegistrierungderTheruleimKundenplugin)? –

Antwort

1

Kurz gesagt: SonarJava unterstützt keine benutzerdefinierten Prüfungen für POM-Dateien (z. B. benutzerdefinierte PomCheck).

Mehr Details

Per Java custom rules tutorial, benutzerdefinierte Regeln müssen sie getJavaChecks durch Einspeisen aktiviert werden (Häkchen gegen Quelldateien) oder getJavaTestChecks (geprüft gegen Test-Dateien). Die Sache ist, dass pom.xml Dateien nicht in eine dieser beiden Kategorien fallen, sie gehören eher zum 'XML-Dateien-Bucket', gegen den bestimmte Regeln geprüft werden.

Eine gute Möglichkeit, dies zu visualisieren, ist ein Blick auf SonarJavas CheckList.java, notieren Sie die dedizierten getXmlChecks und getMavenChecks. Dies sind die Prüfungen, die tatsächlich gegen XML-Dateien ausgeführt werden, die vom Scanner indiziert werden.

Konkret

sprechen Während Sie die Freiheit haben, benutzerdefinierte Regeln zu getJavaChecks oder getJavaTestChecks hinzuzufügen, SonarJava APIs unterstützen keine Regeln getMavenChecks Hinzufügen (Sie können versuchen, aber es wird effektiv nichts tun). Ihre Gesamtanalyse ist ziemlich vor Ort, aber die Tatsache ist, dass nur Pakete mit API durch den Klassenlader (example) zugänglich sind, nicht der Fall von PomCheck.

Mir sind keine Pläne für Änderungen an dieser Front bekannt.

'Denken außerhalb der Box' Vorschlag

SonarXML unterstützt XPath-Ausdrücke mit benutzerdefinierten Regeln (siehe extension guide). Mit ein wenig von XPath gymnastic könnten Sie erwägen, Regel zu verlängern xml: XPathCheck - Verfolgen Sie eine XPath-Regel.

+0

Fair nuff, ich hatte bereits die XPathCheck-Route für einige andere einfachere Regeln heruntergefahren. Ich werde jedoch hier reinhören, um das SQ-Team zu bitten, in Erwägung zu ziehen, dem Java-Plugin Unterstützung für benutzerdefinierte PomChecks hinzuzufügen. Scheint mir, wenn das Basis-Java-Plugin selbst einen PomCheck ausführt, sollte es möglich sein, einen eigenen PomCheck hinzuzufügen. – SCornell