Best practices
Developers of Sonar core should :
- build with maven before commiting to subversion. Continuous integration watches you !
- commit frequently into subversion
- never commit incomplete changes (Subversion is not a backup system)
- use meaningful comments when doing a subversion commit, always with the JIRA key and title (e.g. "SONAR-6 Apply license LGPL")
- subscribe to both mailing-lists user@sonar.codehaus.org and scm@sonar.codehaus.org
- abuse of unit tests (JUnit 4), with the help of mock objects (Mockito)
- think IoC (Inversion of Control pattern)
- abuse of functional tests (Selenium). Tests are written in the Selenese format (HTML).
- use comments and javadocs only when necessary
- do not forget the license header on all Java and Ruby files
- respect the code formatting described below
Code formatting
- replace tabulations by 2 whitespaces
- follow this template :
- never do this :
- but this :
Tips and tricks
Connect to Derby from command line
- download derby(the same version as used by sonar)
- set the DERBY_HOME property
- execute the command $DERBY_HOME/bin/ij
- connect to the database :
Compare XML files from JUnit
Use XMLUnit. The dependency is already defined into maven.
Warning : There's a bug on the similar() method. Contrary to the documentation, it fails if nodes are not in the same order.
Override Object.equals(), hashCode() and toString()
You can use EqualsBuilder and HashCodeBuilder from commons-lang to simplify. Just define the fields to compare. Example on the Rule class :
Debug the Maven plugin from an IDE
1. Edit $MAVEN_OPTS with :
2. Execute Maven : mvn org.codehaus.sonar:sonar-maven-plugin::sonar. It should block on :
3. Attach your IDE to the remote process (the listening port is 8000)

