The latest version of open source code quality management tool Sonar supports architecture constraint rules for Java projects and custom dashboards. SonarSource team released last month version 2.4 of the product. There are four main features in the new release.
Architecture Rules: Architecture constraint rules allow the developers to define the pattern based rules to deny references between classes in different packages. Some examples of patterns include denying access to *.web.* from *.dao.* classes or denying access to java.util.Vector, java.util.Hashtable and java.util.Enumeration from any class. A project complies with an architectural model when its source code adheres to a set of architectural constraints. Java bytecode analysis is required to use this rule.
Custom Dashboards: Sonar users can now create and customize the dashboards for different stakeholders in the company such as managers, developers etc. Customizatin process includes the steps of choosing a layout, adding widgets and putting in place those widgets. Administrators can share dashboards with all users and choose the dashboards to display by default. Future releases of Sonar tool will include new widgets on the dashboards as well as user role based access to the project dashboards.
Update Center: The new Update Center can be used for installing and upgrading plugins. The users can also get the information on the already installed plugins, compatibility verification, check new versions of Sonar and automatically manage the plugin compatibility matrix.
The new release of Sonar also supports Maven 3 for application builds and code analysis. InfoQ spoke with Olivier Gaudin from Sonar team about the new features.
InfoQ: What are the next phase enhancements for the Architecture Rules feature?
In this initial version, the architecture rules engine offers already the ability to define simple rules such as "class / package A should not be used from class / package B". The natural evolution for this is going to be to add the ability to express complex rules through a DSL in order to define architecture layers and then define for example rules like: layer A can only be used from layer B or C. With such functionality built into Sonar, the need for using an external tool for monitoring design will be only occasional.
InfoQ: What is the future road map of the Sonar project?
Our main objective is to make the platform fully operational to support all aspects of Continuous Inspection, to provide development teams the ability to measure and therefore manage their technical debt. We have identified 3 areas that are our next targets to augment this support:
- The next step is coming in Sonar 2.5 with better support to track when a violation is / was added on source code and with differential views on dashboards.
- Add some sort of manual code review capability to the platform for adding, suppressing, commenting, and discussing quality defects.
- Embed a light version of Sonar in the sonar-eclipse plugin to enable code review prior to SCM commit.
In the mean time, we will continue to add new languages using the SonarSource developed parsing technology and consolidate on existing ones by adding new rules to C and Cobol for example.