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 :
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 Atlassian Bamboo Jenkins for continuous integration
- Use this wiki for the documentation
- Most of all, the plugin is available in the Update Center, so users can quickly install the plugin directly from the application
- 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.
- 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)
preferably receive at least one +1 from a voting member of the development mailing list for subsequent releases (although passing a vote by lazy consensus is allowed.)
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
- Publish the source code of your plugin on a public Github repository
- Create an account at CodehausSubscribe and subscribe to email@example.com
- Send an e-mail to firstname.lastname@example.org to explain the purpose of your plugin, detail its features and link to its source code repository
- 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
- Create an account at Codehaus and subscribe to email@example.com
- Send an e-mail to firstname.lastname@example.org and tell us your Codehaus ID, so that we can to explain the purpose of your plugin
- Discussion on the added value of the plugin will take place
Code Your Plugin
- The plugin must support Java 56. The Continuous Integration job uses Oracle JDK 16.5.
- The plugin is must be built with Maven 2.2.* or 3.*.
When you utilize the forge, we request that you respect the following principles :
- Follow Best practices and Sonar Code Style.
- The copyright belongs to whoever wrote the plugin
- The license must be business friendly
- Follow the release process described bellow.
- The directory name is the plugin name.
- The 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 "
Set the following properties:
Code Block title pom.xml lang xml
<project> <parent> <groupId>org.codehaus.sonar-plugins</groupId> <artifactId>parent</artifactId> <!-- The latest version can be found by looking at the tags starting with "parent-" in http://svnsearch.codehausmaven.org/#search|gav|1|g%3A%22org.codehaus.sonar-plugins/tags/plugins%22%20AND%20a%3A%22parent%22 --> <version>REPLACE_BY_LATEST_VERSION</version> <relativePath>../parent</relativePath> </parent> <artifactId>sonar-foo-plugin</artifactId> <version>1.0-SNAPSHOT</version> <packaging>sonar-plugin</packaging> <name>Plugin name</name> <description>Plugin description</description> <url>http://docs.codehaus.org/display/SONAR/MY+PLUGIN</url> <inceptionYear>2011<<inceptionYear>2014</inceptionYear> <organization> <name>My Organization</name> <url>http://www.my-organization.com</url> </organization> <issueManagement> <system>JIRA</system> <url>http://jira.codehaus.org/browse/SONARPLUGINS/component/MY-JIRA-COMPONENT-ID</url> </issueManagement> <scm> <connection>scm:svngit:email@example.com://svn.codehaus.org/sonar-plugins/trunk/MY-PLUGIN<SonarCommunity/MY-PLUGIN.git</connection> <developerConnection>scm:svngit:firstname.lastname@example.org://svn.codehaus.org/sonar-plugins/trunk/MY-PLUGIN<SonarCommunity/MY-PLUGIN.git</developerConnection> <url>http<url>https://svn.sonar-plugins.codehaus.org<github.com/SonarCommunity/MY-PLUGIN</url> <tag>HEAD</tag> </scm> ... </project>
- Configure your pom by overriding values provided by parent - see Sonar SonarQube Plugins Forge Parent POM. Default license is LGPL3.
- Follow Maven POM Code Convention
- Add the plugin to the main pom of the forge
Please send an email to the dev mailing list in order the plugin to be added to our Continuous Integration server.
How to Release
- 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 email@example.com
- 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 analysis of plugins on Nemo
The following configuration of code style must be applied.
- Install Anyedit Eclipse Plugin
- Optional: if Maven projects do not define the profile ‘m2e’, then install the M2E error disabler plugin
- Restart Eclipse
- Windows → Preferences
- 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
- Open the Maven project: File → Import → Maven → Existing Maven Projects → select the root directory containing the file pom.xml
- Open the Maven project: File → Open Project → select the file pom.xml
- Use UTF-8 encoding: Project Settings → File Encodings → IDE Encoding: UTF-8
- Configure code style
Release Your Plugin
The release process is detailed on this page.