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 90 Next »

Tempted to write your own plugin? Want to contribute your plugin back to the community? If you do, we'd be happy to host your FOSS plugins in the SonarSource plugin forge. After all, it gives you a broader audience and enhances the community. Everyone’s a winner. Plus:

  • It's easier for the community to help you
  • Source code is hosted in the Github organization named SonarCommunity
  • Use JIRA to track issues
  • Use Jenkins for continuous integration
  • Use this wiki for documentation
  • Most of all, the plugin is available in the Update Center, so users can quickly install the plugin from the SonarQube web interface

If you're not interested in writing your own plugin, but just want to see what's currently being hammered into shape in the forge, check out the plugins under development.

Request Hosting

Before we can host your plugin in the forge, there are a few rules we must ask you to follow:
  • follow the coding conventions (see below)
  • do not be misleading in terms of content (the code needs to do pretty much what the name and description say it does)
  • have a business-friendly license (the default license is LGPL3)
  • do not compete with existing SonarSource products (sorry, but we gotta pay the bills somehow)
  • receive +1’s from three voting members of the development list and no -1’s for the initial release

To keep your plugin in the forge, it must remain in compliance with everything on the first list and:

  • be maintained over time (meaning you should pay attention to the mailing lists and respond to bugs and API changes)

  • receive at least one +1 from a voting member of the development mailing list for subsequent releases

If any of these requirements are not met, or stop being met (if, for example you change the license to one that’s not business-friendly) we may remove the plugin from the forge immediately

Sharing an existing plugin

  1. Publish the source code of your plugin on a public Github repository
  2. Create an account at Codehaus and subscribe to
  3. Send an e-mail to to explain the purpose of your plugin, detail its features and link to its source code repository
  4. Reviews will be performed by contributors on both the added value of the plugin and the quality of the source code

Beginning development of a new plugin

  1. Create an account at Codehaus and subscribe to
  2. Send an e-mail to to explain the purpose of your plugin
  3. Discussion on the added value of the plugin will take place

When the plugin is approved, send your Codehaus ID to and we'll give you a commit access to github.

Code Your Plugin


  • The plugin must support Java 5 (Java 6 since March 2013). The Continuous Integration job uses Oracle JDK 6.
  • The plugin must be built with Maven 2.2.x or 3.x

Maven POM

  • The directory name is the plugin name
  • The groupId is org.codehaus.sonar-plugins and artifactId sonar-<name>-plugin. For example the plugin "foo" is stored in the directory foo and its artifact id is sonar-foo-plugin.
  • Set the following properties:


  • Configure your pom by overriding values provided by parent - see SonarQube Plugins Forge Parent POM. Default license is LGPL3.
  • Follow Maven POM conventions
  • Add the plugin to the main pom of the forge

Continuous Integration

Send an email to, so we can add the plugin to Jenkins.


  • Do not commit incomplete changes (Git is not a backup system)
  • Do not commit IDE files (.settings, .project, .classpath, .idea, *.iml, *.ipr, *.iws)
  • Use meaningful comments when doing a commit, always with the JIRA key and title (e.g. "SONARPLUGIN-1234 add rule FOO") - see this note about Git commit messages
  • Subscribe to the mailing list
  • Overuse JUnit tests with the help of FEST Assert and Mockito
  • Use comments and javadocs only when necessary
  • Do not forget the license header on all Java and Ruby files
  • Source code encoding should be set to UTF-8 to prevent cross-platform encoding issues. UTF-8 is specified in parent POMs, so it is used by Maven when building the projects. However, it may not be set by default in your prefered IDE. The best practice is to force it for all your source code.
    • For Eclipse : go to "Preferences -> General -> Workspace" and force the "Text file encoding" to "UTF-8"
    • For IntelliJ IDEA : go to "Settings -> File Encodings" and force the "IDE Encoding" to "UTF-8"
  • Replace tab characters with 2 space characters
  • Be aware of the inspection of plugins on Nemo

IDE Support

The following configuration of code style must be applied.

  1. Install Anyedit Eclipse Plugin
  2. Optional: if Maven projects do not define the profile ‘m2e’, then install the M2E error disabler plugin
  3. Restart Eclipse
  4. Windows → Preferences
    • General
      • Workspace
        • Text file encoding: UTF-8
      • Editors → AnyEdit Tools
        • Remove trailing whitespace
        • Create new line at the end of file
        • Convert tabs – spaces
        • Default convert mode on save: Tabs to spaces
    • Java → Code Style
    • XML → XML Files → Editor
      • Indent using spaces
      • Indentation size: 2
  5. Open the Maven project: File → Import → Maven → Existing Maven Projects → select the root directory containing the file pom.xml
IntelliJ IDEA
  1. Download sonar-codestyle.xml to
    • ~/Library/Preferences/IntellijIdea/codestyles/ on Mac OS
    • ~/.IntellijIdea/config/codeStyles/ on Linux
    • ~\.IntellijIdea\config\codeStyles\ on Windows
  2. (Re)start IntellIJ IDEA
  3. Open the Maven project: File → Open Project → select the file pom.xml
  4. Use UTF-8 encoding: Project Settings → File Encodings → IDE Encoding: UTF-8
  5. Change the code style: Project Settings → Code Style → Scheme: sonar

Release Your Plugin

The release process is detailed on this page.

  • No labels