Recently, we released the SonarQube Java 1.4 plugin ecosystem, and as announced in What’s coming up for SonarQube in 2013, we’re working hard to progressively deprecate as many Checkstyle and PMD rules as possible, and write native replacements for them using the SonarQube Java rule engine. We’ll continue to support both tools for the foreseeable future, but the goal is to remove them from the default SonarQube Java plugin ecosystem package.

Fans of those two mature, well-known Java quality tools may wonder why we’re moving away from such popular tools. There are in fact several good reasons behind this move :

• Productivity: the activity is low on both projects. In the past, we invested time in updating both tools to support the new language features in Java 7, but in the long term it’s not a viable approach for SonarSource. Continuing to support these tools – both directly with our commits to those code bases, and indirectly – means to working on three different source code analysis stacks: Antlr for Checkstyle, Javacc for PMD, and SSLR for SonarQube’s own Java rule engine.
• Performance: analyzing a project with SonarQube while using Checkstyle and PMD rules leads to parsing the same Java files three times: once each with Antlr, JavaCC and SSLR
• Functional overlap between rules: There is a big overlap between Checkstyle and PMD rules (and in fact even with some Findbugs rules), which makes it difficult to define and manage a Java quality profile.
• Too many configuration options: in a perfect world, a good quality rule is a rule WITHOUT any configuration options. The user should not have to understand what a token is, or what an AST is, and he should not have to tune configuration options to start playing with a rule. On new SSLR rules, we do our best to cover all the use cases, to avoid generating false positives so the user isn’t bothered with configurations.
• Rule descriptions: however perfect a rule implementation is, the rule is worthless without a good description. A rule’s description should always clearly state its purpose, so the reader isn’t left to experimentation to truly understand what a rule does.

None of this is to say that Checkstyle and PMD aren’t great Java tools with wide user bases. They are. But whatever we do at SonarSource, we always try to do it with the long term in mind. And in the long term, it’s well worth migrating existing Java rules to the SonarQube-native Java SSLR engine.

As you use Sonar more and more, it becomes the central place for code quality management. The result of every analysis goes to the database and adds to the precious history of data. You are now relying so much on Sonar that you want to protect your measures .

Since you still want to test new coding rules, different parametrization, add alerts or try a new plugin in Sonar… it is time to create a sand box to try all that. But how to then apply the changes to your production environment without having to duplicate the work already done ? Here is how to do it in 7 steps :

1. Stop the production server

2. Backup the production database

3. Copy the possible plugins from sand box onto the /extensions/plugins directory in production

4. Copy the possible custom coding rules from sand box onto the /extensions/rules directory in production

5. Re-start the production server

6. Export the sand box Sonar’s configuration. To do so, sign in on the sand box Sonar environment, go to configuration and select the Backup / Restore entry in the left menu. Click on Backup and save the file.

7. Import the configuration onto production. To do so, sign in on the production Sonar environment, go to configuration and select the Backup / Restore entry in the left menu. Click on Browse to select the backup file and press restore.

The promotion process is completed ! As this process is quite straightforward, there is no more need to play with your Sonar production environment and your historical measures are now safe.

Last month, Sonar 1.6 was released. The main feature of the new version is the ability to manage quality profiles. The purpose of this post is to explain what gap the functionality fills, to define what is a quality profile and to explain how to use it.
Prior to Sonar 1.6, it was only possible to run analysis with one set of defined coding rules per instance of Sonar. It means that within an instance of Sonar, it was not possible to process differently various types of projects (legacy application, technical libraries, new projects, …). They were all analyzed with the same set of rules. Therefore there was sometimes unnecessary noise around the quality data that made it difficult to see quickly what real action was required. Sonar 1.6 turns off this noise by allowing to define and simultaneously use several quality profiles.

Read the rest of this page »