- Install SonarQube following instructions here.
- Then install the Sonar plugin into Hudson using Update Center and configure it following these instructions
- Lookup how to build the Industrial SQL Connector for Mylyn with Hudson here
Configuring the Industrial SQL Connector for Mylyn for analysisWhether you want to analyze projects with the Maven
sonar:sonartarget or use the Hudson Invoke Standalone Sonar Analysis build step in both cases you need to create a
sonar-project.propertiesfile. As a matter of common sense I always put this file in the same project as the project with the maven master POM, in this case
# required metadata sonar.projectKey=com.industrialtsi.mylyn sonar.projectName=Industrial SQL Connector for Mylyn sonar.projectVersion=0.9.10-SNAPSHOT # optional description sonar.projectDescription=Industrial SQL Connector for Mylyn # path to source directories (required) #sonar.sources=src THIS IS SPECIFIED PER MODULE # path to project binaries (optional), for example directory of Java bytecode #sonar.binaries=target/classes THIS IS SPECIFIED PER MODULE # optional comma-separated list of paths to libraries. Only path to JAR file is supported. #sonar.libraries=lib/*.jar THIS IS SPECIFIED PER MODULE # The value of the property must be the key of the language. sonar.language=java # modules one for each area of functionality, only plugin and fragment projects sonar.modules=core,derby,jpa,memory,ui # setup project base dir core.sonar.projectBaseDir=com.industrialtsi.mylyn.core derby.sonar.projectBaseDir=com.industrialtsi.mylyn.demo.derby jpa.sonar.projectBaseDir=com.industrialtsi.mylyn.demo.jpa memory.sonar.projectBaseDir=com.industrialtsi.mylyn.demo.memory ui.sonar.projectBaseDir=com.industrialtsi.mylyn.ui #set up source folders core.sonar.sources=src derby.sonar.sources=src jpa.sonar.sources=src memory.sonar.sources=src ui.sonar.sources=src # set up binary folders core.sonar.binaries=target/classes derby.sonar.binaries=target/classes jpa.sonar.binaries=target/classes memory.sonar.binaries=target/classes ui.sonar.binaries=target/classes # set up libraries folders, where jars reside core.sonar.libraries= derby.sonar.libraries=lib/*.jar jpa.sonar.libraries=lib/*.jar memory.sonar.libraries= ui.sonar.libraries=Then we commit this file to the repository so Hudson can retrieve it.
Configuring Hudson to analyze the projectWe go to the Hudson Job tab and press configure. Under Build we add a step Invoke Standalone Sonar Analysis and configure it as follows:
Building and examining the resultsWe make Hudson build the project and then go over to the SonarQube pages for the results, note that I have created a custom set of my favorite widgets for this: The Technical Debt widget tell us the technical debt in days, and also a percentage split of the main problems. Lack of coverage explains half the debt, with design, comments and complexity as other issues. There are very few violations and duplications, the happy result of running with Checkstyle, Findbugs and PMD inside Eclipse during the development. I always add a Most Violated Rules widget to the project dashboard. Exposing internal representation is the most common here as the very bad package cycles. The "Most Violated Resources" widget instantly tells me that the objects used to ferry query parameters around are the main problem area. I have a tagged sonar-project.properties file so I will be able to see progress in the future on lines of code, technical debt and documented API. Issues are mostly Critical and Major, so need to be fixed urgently. 1% duplications is not that serious, even though 0% is best of course. Test coverage is more serious as we've seen above that lack of Test Coverage accounts for half of technical debt. This maybe because the build is not yet configured to execute tests. The complexity stats show mainly whether design is good, a method should do one thing, a class should have one responsibility. The LCOM4 measure of 1.0/class is quite positive. The main problem in these is the startling 40.5% of package tangle index and more than 10 cycles! This needs to be looked at with highest priority.
Action PlanSo this short exercise (total time to setup 1,5 hours) revealed quite a lot of potential problems in the code base! How then to tackle and resolve these problems?
- Ensure that the unit tests are executed and measured! Without unit tests we cannot begin to refactor safely.
- Fix the Critical Issues in the code, but only when adequately covered by unit tests
- Investigate and fix the Package Cycles problems, but again only when adequately covered by unit tests
- Fix the Major Issues in the code, but only when adequately covered by unit tests
- Fix the Code Duplications problems