Looking back at 2013 SonarQube Ecosystem Accomplishments

by freddy mallet|

    A new year provides a good opportunity to look back at what was achieved the previous year. I'll do that for the SonarQube platform in this post.

    Let’s start with a summary of this retrospective. Last year:

    • the platform was renamed into SonarQube
    • 5 releases of SonarQube platform
    • 130 releases of ecosystem products
    • 75,000+ downloads of SonarQube
    • 13,000+ messages on mailing lists


    So I suppose we can call this a pretty active year for the community. Now, the longer version:


    The Plan


    One year ago, we had the following ambitions :

    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.

    Preview analysis



    See this recent blog entry to know more about this feature Analysis vs. Preview vs. Incremental Preview in SonarQube

    SQALE available out-the-box



    See this recent blog entry to know more about this feature SQALE models – more than just tiny cities*

    JavaScript and Flex plugins



    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!