The Plan

To cover the Java language, we still rely a lot on Checkstyle and PMD. We want to migrate a substantial number of those rules onto our own technical stack (see SSLR). The objective for 2014 is to not rely anymore on Checkstyle and PMD to get full control of the stack and so to increase significantly the level of support we can provide: reduce the noise, ease migration on new java versions,…

DONE, with SonarQube Java ecosystem 2.0. Moreover, the description of most Java rules have been significantly improved. Indeed the completeness of a rule description is as important as the quality of its implementation.

Make the Eclipse plugin support incremental analysis

DONE. Now only updated source files are analyzed locally, making the SonarQube plugin usable even with large projects.

Lines covered by one unit test, getting the answer to the following questions: How many and which unit tests are covering this line of code? How many and which lines of code are covered by this unit test ?

DONE. The feature is available for Java projects.

Merge the two close Violations and Reviews concepts into Issues

DONE, and it is now possible to search for issues across all projects and not just project by project.

C and C++ plugin take off

DONE. We still have a long journey ahead, but we’ve managed to greatly improve our parsing technology by supporting what makes C++ one of the most complex languages: ambiguities. From there, we still need to work hard to provide more and more C++ rules.

Cartography. Behind this word, we group many features based on the dependencies between methods, attributes, classes, files, modules, projects, teams, departments… Here are the first use cases that we’ll cover: impact analysis and cross-sources navigation.

This was one of our most ambitious objectives for last year, and we decided to postpone it because we didn’t have the right back-end technology to correctly support this kind of feature. That’s why we started embedding ElasticSearch in SonarQube 4.1, and we are relying more on more on this NOSQL backend.

Ability to track and review new code

We also postponed this for a functional reason: it isn’t hard to extend the SonarQube platform to provide a post-commit code review tool, but providing a pre-commit code review mode and the ability to fully support branches is another story. Eventually, we want to provide a complete code review system, but before we start investing in code review features, we want to be able to sustain the effort in the long term, and that’s not yet the case.

Beyond the plan

Rule descriptions

As mentioned above, we have invested heavily in rule descriptions for all language plugins to standardize their format and to make them as meaningful as possible. This effort started 6 months ago and we will sustain it throughout the development of the platform. Any feedback is of course welcome to keep on improving current rule descriptions.

For these two language plugins we decided to drop the use of external engines like JSLint and FlexPMD. Instead, we decided to fully base those plugins on our source code analysis stack (SSLR), thus making them first-class language plugins. See this blog entry SonarQube JavaScript plugin: why compete with JSLint and JSHint?

IntelliJ IDEA plugin

And last but not least, we’ve finally decided to develop a SonarQube IntelliJ plugin to finally support the most popular Java IDE.

So after all this, what could be the exciting challenges for 2014? That will be the subject of my next post!