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 5 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, subscribe and send an email to the Sonar development mailing list. You will then benefit from the Sonar plugins forge to publish the plugin, have access to Subversion to store the source code and to JIRA to file your issues.

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

  1. A plugin is built with Maven 2.
  2. When you create a plugin called 'foo', it should be stored in the directory 'foo'. Maven groupId is 'org.codehaus.sonar-plugins' and artifactId is  'sonar-foo-plugin'.
  3. Add the plugin as a module of ../pom.xml
  4. After creation, send an email to the dev mailing for it to be added to Continuous Integration server (Bamboo)
  5. The copyright belongs to whoever wrote the plugin, however the license should be business friendly (see "Choose license" below)

Request hosting

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

Choose license

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.

Releasing a plugin

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

Prepare for the first release

When a plugin is ready to have its first release, you should do the following :

  1. Set the <scm> tag in the pom :
  2. Check that group id is org.codehaus.sonar-plugins in pom.xml, but not org.codehaus.sonar.plugins
  3. Set your Codehaus username/password in Maven settings.xml :
  4. Add the plugin to the main pom in the forge
  5. Request on the development mailing list that a Bamboo build is added for the plugin

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 maven-release-plugin, use default values :
  3. Update the plugin page with new version info (the jar file is available under http://repository.codehaus.org/org/codehaus/sonar-plugins/)
  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 announce@sonar.codehaus.org, user@sonar.codehaus.org and dev@sonar.codehaus.org (you must subscribe to these lists in xircles )
  8. Tweet it (big grin)
  • No labels