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 sonar-plugins.codehaus.org 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 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
- Create an account at Codehaus
- Subscribe to firstname.lastname@example.org
- Send e-mail to email@example.com 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 :
- A plugin is built with Maven (2.0.9+).
- You should follow Best practices and Sonar Code Style.
- 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'.
- Add the plugin as a module of ../pom.xml
- After creation, send an email to the dev mailing for it to be added to Continuous Integration server (Bamboo)
- The copyright belongs to whoever wrote the plugin, however the license should be business friendly (see "Choose license" below)
Parent Maven project
Use the following parent in your pom :
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 :
- Define licenses, inceptionYear and organization in your pom.xml file :
- Place license-header.txt to your src directory (example of this file can be found here).
- 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 :
- Set the <url> tag in the pom :
- Set the <issueManagement> tag in the pom :
- Set the <scm> tag in the pom :
- Check that group id is org.codehaus.sonar-plugins in pom.xml, but not org.codehaus.sonar.plugins
- Add the plugin to the main pom in the forge
- Install Codehaus SSL certificates :
- download startssl-CA.pem and startssl-Intermediate.pem from this page.
- execute the command for both certificates (password is changeit): - add these properties to MAVEN_OPTS:
- 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
- Close the vote on the dev mailing list
- Execute the maven-release-plugin, use default values :
- Update the plugin page with new version info (the jar file is available under http://repository.codehaus.org/org/codehaus/sonar-plugins/)
- Update the Changelog using the jiraissues macro
- Release the version in JIRA
- Update the version compatibility matrix
- Announce the release in the mailing-lists firstname.lastname@example.org, email@example.com and firstname.lastname@example.org (you must subscribe to these lists in xircles )
- Tweet it