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

Tempted to go ahead and write your own plugin ? No obligation, but you might want to share it with the Sonar community. In that case hosting your plugin at brings you many benefits :

  • the community helps you more easily, as well as the community benefits from the plugin
  • free hosting in the subversion repository
  • use JIRA to track issues
  • use Atlassian Bamboo for continuous integration
  • use this wiki for the documentation
  • the plugin is automatically shown in the update center (feature to come soon), so users can install the plugin directly from the application 

Request hosting

  1. Create an account at Codehaus
  2. Subscribe to
  3. Send e-mail to and tell us your Codehaus ID, so that we can give you a commit access to subversion.


When you utilize the forge, we request that you respect the following principles :

  1. A plugin is built with Maven
  2. You should follow Best practices and Sonar Code Style.
  3. The copyright belongs to whoever wrote the plugin, however the license should be business friendly (see "Choose license" below)

Maven POM

  • The directory name is the plugin name. Maven groupId is 'org.codehaus.sonar-plugins' and artifactId is 'sonar-<name>-plugin'. For example the plugin "foo" is stored in the directory "foo" and its artifact id is "sonar-foo-plugin"
  • Use the following parent :
  • Configure your pom by overriding values provided by parent - see Sonar Plugins Forge Parent POM
  • Follow Maven POM Code Convention


Starting from Sonar plugins parent POM version 4 we are using maven-license-plugin for checking and for managing license headers in source files (currently only java-files).

Here is a brief description of how we recommend to use this plugin :

  1. Define licenses, inceptionYear and organization in your pom.xml file :
  2. Place license-header.txt to your src directory (example of this file can be found here).
  3. Add/update headers of your source files :

For detailed instructions on how to use this plugin see plugin homepage.

Continuous integration

Send an email to the dev mailing in order the plugin to be added to our Continuous Integration server.

Releasing a plugin

Configure Maven

  • Install Maven 2.0.x, not Maven 2.1+ (see MNG-4301)
  • Add your codehaus credentials to maven settings (~/.m2/settings.xml) :
  • Install Codehaus SSL certificates into JDK

Prepare to Release

  • Make sure the wiki page is up to date
  • All JIRA issues included in the release should be closed
  • Plugin must be documented and preferably have tests
  • Run mvn deploy in order to publish the snapshot version for tests

Call a Vote

Before a release can occur, a vote typically takes place. This is initiated with an email to the dev mailing list with a link to the snapshot version, preferably with a subject that starts with [VOTE]. Explain the plugin, status and any other info you feel relevant. The standard is to wait 72 hours for responses. This gives other developers time to verify the validity of the plugin before placing their vote. Votes are represented as numbers between -1 and +1, with -1 meaning 'no' and +1 meaning 'yes.'

Only Sonar plugin commiters can vote. To pass, a vote should :

  • have a minimum of three +1
  • have no -1

Perform the Release

  1. Close the vote on the dev mailing list
  2. Execute the following with Maven 2.0.x, not Maven 2.1+ (see MNG-4301) :
  3. Update the plugin page with new version info (the jar file is available under
  4. Update the Changelog using the jiraissues macro
  5. Release the version in JIRA
  6. Update the version compatibility matrix
  7. Announce the release in the mailing-lists, and (you must subscribe to these lists in xircles )
  8. Tweet it (big grin)
  • No labels