Message-ID: <1788744703.1787.1430004623398.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1786_1599698728.1430004623397" ------=_Part_1786_1599698728.1430004623397 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A SonarQube plugin is a set of Java objects that implement extension poi= nts. These extension points are interfaces or abstract classes which model = an aspect of the system and define contracts of what needs to be implemente= d. They can be for example pages in the web application or sensors generati= ng measures.
The extensions implemented in the plugin must be declared in a Java clas= s extending org.sonar.api.Plugin. This class must then be declared in the p= om with the property <pluginClass>:
The sonar-plugin packaging accepts ad= vanced parameters.
An extension point is a point in the application where plugin code can b= e invoked, such as webapp page or code analyzer. Extension points are gener= ally interfaces that can be implemented by plugins. Implementations have to= be declared in the method org.sonar.api.SonarPlugin#getExtensions() and ar= e then injected in the IoC container.
The extension points are listed and documented in the Javadoc. See http://docs.sonarso= urce.org/latest/apidocs/index.html?org/sonar/api/Extension.html.
A SonarQube analysis follow the following lifecycle:
There are two extension points that allow plugins to save measures: Sens= or and Decorator. A common problem when writing a plugin is to decide which= one to use.
A Sensor is invoked once during the analysis of a project. The sensor ca=
n parse a flat file, connect to a web server... For example the Cobertura S=
ensor is able to parse the cobertura XML report file generated during execu=
tion of your tests and used to save the first-level of measures on resource=
s (project, package or class).
A sensor can access and save measures = on the whole tree of resources. Sensor are generally used to add measure at= the lowest level of the resource tree.
Decorators are triggered once all sensors have completed. Their decorate=
method is called on every resource of a certain level bottom up. Decorator=
s can read and save measures. The call is contextual, i.e it is only possib=
le to access the resource and its children.
Decorators are generally = used to consolidate / aggregate at higher levels, measures saved by Sensors= at the lowest level.
Extensions are registered in an IoC container, with constructor injectio= n. To communicate with other extensions or with existing components provide= d by the API, just declare them in the constructor of your extension. For e= xample to get references on FileSystem or ActiveRules:
References will be automatically set at runtime.
As described in the Getting Started page, you can build sources, copy th= e JAR file to the directory extensions/plugins/ and restart the server. But= this approach can quickly become tedious. The following solutions help to = edit code without leaving your development environment:
The sonar-dev-maven-plugin lets you start a SonarQube server and deploy = your plugin.
Once the server is launched, hit http://localhost:9000. By default,= the in-process database (H2, or Derby prior to SonarQube 3.2) is used but = you can specify a local MySQL instance instead with the property "-Dso= nar.database=3Dmysql". In that case, the sonar schema must exist in th= e MySQL DB along with the user sonar/sonar (login/password) which must have= all rights on the sonar schema.
Then you can feed the database by inspecting projects:=20 =20 =20
We've gathered all our debugging tips into this page.
How to Use External Libraries
A plugin benefits from all the dependencies provided by the API. Execute= the following command on your plugin to list them:
Since version 2.2, the plugin classloader is isolated from other plugins= , so it can embedd its own dependencies. Just define the dependencies you n= eed with the scope 'compile'.
SLF4J is used as a simple facade of various logging frameworks (log4= j, commons-log, logback, java.util.logging). It's simple to use:
Read the SLF4J manual for more details.
org.sonar.api.config.Settings provides proper=
ties for batch extensions (global/project settings, command-line parameters=
, system properties) and server extensions (global settings, system propert=
ies, file $SONAR_HOME/conf/sonar.properties). It replaces Apache Commons Configuration that is deprecated since release 2.=
To benefit from advanced features (default value, availability in the se= ttings page), properties should be declared on the Plugin entry point or on= extensions:
Persistent properties are also accessible from the Web Service named 'properties'. To exclude some p=
roperties from anonymous requests, add the suffix ".secured" to t=
he key (
my.property.secured). It can be useful for license key=
s for example.
ca= rdinalityfield to