Full documentation for SonarQube has moved to a new location: http://docs.sonarqube.org/display/SONAR

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Table of content

 

Icon

The following documentation has been written for Sonar versions >= 2.3.

There are two ways to extend coding rules :

  1. Extend an existing Sonar plugin. For example Checkstyle and PMD plugins accept definition of custom checks.
  2. Embed and execute a code analyzer. For example the Checkstyle plugin configures and executes the library Checkstyle. 

Solution 1: Extending Sonar plugins

The following plugins can be extended with new rules :

  • Checkstyle (Java)
  • PMD (Java)
  • C, freeware plugin provided BySonarSource
  • Cobol, commercial plugin provided by SonarSource

Checkstyle (Java)

Checkstyle provides extension mechanisms to develop your own coding rules. Tutorials to write such custom rules are available online. You can for instance define your own naming conventions, forbid access to a given API or anything else that is relevant in your context.

Once written, the Checkstyle classes must be packaged in a JAR file. This file must be copied in the directory $SONAR_HOME/extensions/rules/checkstyle/. A XML file must then be created in the same  directory to "index" all the new rules. The name of this XML file doesn't matter but the .xml suffix must be used. This XML file must look like the following example :

PMD (Java)

The PMD coding rules must be packaged in a JAR file and this file must be copied in the directory $SONAR_HOME/extensions/rules/pmd/. Moreover, the JAR file must also contain the PMD ruleset XML file (in the following example, this XML file will be available through the classloader with the following path : rulesets/myruleset.xml)

A XML file must then be created in the same $SONAR_HOME/extensions/rules/pmd/ directory to "index" all available custom rules implemented in the JAR file. The name of this XML file doesn't matter but the .xml suffix must be used.

This XML file must look like the following example :

A full example is published in sonar sources. See the XML file and the Maven project

Since Sonar 2.3, it's also possible to define XPath rules directly into this XML file without any need to provide an additional JAR file. Here is an example of XPath rule defintion :

C

Read the plugin ocumentation.

Cobol

Read the plugin documentation.

Solution 2: Executing a code analyzer

A code analyzer plugin executes the following steps :

  1. Register definitions of coding rules, when the server is started.
  2. Optionally define some templates of quality profiles, when the server is started.
  3. Analyze source code and inject results in database 

1. Registering coding rules

This step relates to the extension point org.sonar.api.rules.RuleRepository. A RuleRepository defines a set of coding rules. It usually loads data from a XML file :

The XML file is available in the plugin classloader and looks like :

2. Defining quality profiles

This step relates to the extension point org.sonar.api.profiles.ProfileDefinition. Profiles provided by plugins are registered at server startup  and can't be edited by users :

3. Analyzing source code

This step relates to the extension point org.sonar.api.batch.Sensor.

  • No labels