Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

5 Java powered open source tools for your team
By Alex Collins, 27 August 2010
If you’re a Java shop and want to ensure you can support your team’s toolset, here are some pointers for the must-have tools we modern developers use day-to-day.

Killer tool: Sonar
By Erwin Vervaet, 27 August 2010
Today a colleague at work showed Sonar to me, and I must say that I was really impressed! Sonar is an open source code quality analysis tool that uses a number of popular Java code analyzers like PMD, CheckStyle, FindBugs and Cobertura under the hood, …

Cross-referencing plugins in Sonar 2.2
By Josh Cummings, 19 August 2010
Formerly, we had three Sonar plugins, two “mavenly” dependent on the other. The parent plugin held the common code for uploading non-Java files into Sonar for reporting. The other two took care of analyzing xml and css, respectively, and tying violations to those files.

Integration Tests in Sonar
By Josh Cummings, 19 August 2010
Integration tests are another important aspect of analyzing a project’s overall health that Sonar does not yet support out of the box. To get this functionality, you’ll need to build a couple of Sonar plugins (or try using the ones that I built) that will instrument your integration test code, run the integration tests, and collect the integration test results as well as the new coverage data.

Architecture Analysis Tool SonarJ 6.0 Supports Structural Debt Index and Quality Model
By Srini Penchikala, 16 August 2010
The latest version of software architecture analysis and quality governance tool SonarJ supports structural debt index metrics and architecture quality model. The company behind the product, hello2morrow, last month announced the release of version 6.0 of the tool.

Maven 3 and Sonar
By Anders Hammar, 16 August 2010
Another step towards a final release of Maven 3.0 was made the other day when version 3.0-beta-2 was released. I’ve been using Maven 3 since its alpha days, and despite the alpha/beta moniker, I find it to be superior to any Maven 2.x version. If you are starting a new project, I strongly recommend using Maven 3.

Reporting more than Java code in Sonar (Part I)
By Josh Cummings, 3 August 2010
Of course, anyone that has done static analysis on their project in the past has found certain bad practices that are out of their tools reach to spot. Some examples are…

By default, Sonar embarks two tools to calculate code coverage by unit tests on java projects : Cobertura and Clover. But last week, we also released plugins for two other coverage tools : Emma and JaCoCo. Both plugins are available in the Sonar Plugin Library. So I thought it would be a good time to compare all of them and share the results with the community.

Clover Cobertura Emma JaCoCo License Commercial GNU GPL CPL EPL Latest stable release 3.0.2
(13 April 2010) 1.9.4.1
(3 March 2010) 2.0.5312
(13 June 2005) 0.4.0
(4 June 2010) Type of instrumentation Source code instrumentation Offline bytecode instrumentation Offline bytecode instrumentation On-The-Fly bytecode instrumentation Java 1.4+ 1.3+ 1.2+ 1.5+ Line hits yes yes yes yes Branch coverage yes yes no no (but planned) Process within Sonar Instrumentation
Compilation
Execution
Report generation
Report parsing Instrumentation
Execution
Report generation
Report parsing Instrumentation
Execution
Data reading Execution
Data reading

To compare results and performance of those tools I’ve used following projects:

Lines Statements Lines of code Classes Tests Sonar LDAP Plugin 0.1 925 201 459 8 9 Struts 1.3.9 114621 21896 50080 518 323 Commons Collections 3.3RC1 64447 12402 26558 412 13023

And here is code coverage results:

Clover 2.6.3 Clover 3.0.2 Cobertura 1.9.4.1 Emma 2.0.5312 JaCoCo 0.4.0 Sonar LDAP Plugin 0.1 Line coverage 91.9 91.9 88.8 86.7 88.0 Branch coverage 73.4 73.4 75.0 N/A N/A Struts 1.3.9 Line coverage 15.7 15.7 15.4 14.8 15.4 Branch coverage 14.6 14.6 12.8 N/A N/A Commons Collections 3.3RC1 Line coverage 82.5 82.9 82.1 81.1 82.4 Branch coverage 78.7 78.8 78.6 N/A N/A

And finally I’ve made three measures of time of Sonar analysis for each combination of project and tool with clean Sonar database (which means 54 builds on my Intel(R) Core(TM) i3 CPU M 330 @ 2.13GHz). For this I’ve used Maven 2.2.1 with Java 1.6.0_20 and Sonar 2.2.

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Jouez les Docteurs Love, apprenez à nettoyer du vieux code
By Le Touilleur Express, 28 July 2010
La vie d’un développeur ce n’est pas toujours de travailler à la création d’une nouvelle application. Au contraire nous serons souvent amené à faire ce que j’appelle de l’Archéologie. Cela veut dire entrer dans du code écrit il y a quelques années, être capable de faire fonctionner une vieille application, et surtout, être capable de la moderniser sans l’abimer. J’ai regroupé quelques outils et quelques pratiques apprises ces dernières années, mais n’hésitez pas à compléter.

Zoom sur… sonar, pour automatiser la vérification de la qualité du code java
By Guillaume Saint-Raymond, 28 July 2010
La qualité du code est souvent le parent pauvre des projets en entreprise et, pourtant, celle-ci a un impact sur la productivité. Sonar est le tableau de bord permettant de suivre l’évolution de la qualité des sources au fur et à mesure de la vie d’un projet.

Maintaining High Quality Code with Sonar
By RJ Salicco, 27 July 2010
Is your app so brittle that if you stare at it for too long that it may break causing an all weekend outage?
Does your app contain smelly dead code?
Are your code review sessions a waste of your time?

Android and Sonar
By Brett Dubroy, 21 July 2010
Continuing from the Android and Continuous Integration note, we’d also like to hook up our metrics gathering tool (Sonar – http://www.sonarsource.org/) into our CI builds of our android applications on Hudson.

Technical Debt and the Boogie Monster
By Joel Tosi, 19 July 2010
Growing up as the youngest child meant that my closest brother (6 years my elder) terrorized me with threats of the boogie man coming to get me. It was a rather effective tactic – how to deal with the boogie man wasn’t well known, and the internet was just a glimmer in Al Gore’s eye.

The Sonar team is proud to announce the release of Sonar 2.2. As usual, this new release includes numerous improvements, bug-fixes and also brand new features that we believe are worth stopping your daily work for a few minutes to review. Those features can be divided into three categories :

• Favourites resources
• Filters homepage
• Plugin classloaders

Favourites

When you are working in a company that makes an intensive usage of Sonar, the project(s) you want to monitor can be quickly lost among hundred of others projects. Favourites makes it possible to flag those projects but also modules, packages and files. You then get quickly an overview of those resources at any time.

To use this feature, the user must be logged into Sonar. Resources can then be flagged by clicking on the star icon available in the “Dashboard”, “Components” and “Filters” pages :

Once a resource is flagged as a favourite, it is automatically displayed in the “My Favourites” tab in the homepage :

Filters

The Sonar homepage had several drawbacks when Sonar was intensively used :

• Displaying the page took too much time with more than 500 projects
• Only root projects were displayed
• There was no way to quickly get a list of resources according to some criteria. For instance, the list of projects whose technical debt ratio is greater than 10%, the list of Files whose complexity is greater than 300…
• The Treemap was too small and so not usable with many projects
• There was no way for a user to customize the homepage

The new “Filters” page allows to overcome those limitations :

Of course, this feature comes along with configuration capabilities :

Plugin classloaders

Plugins are now executed in independent classloaders. The main advantage is that plugins can declare and embed their own dependencies instead of being limited to libraries provided by Sonar. As a direct consequence, Sonar no longer depends on Maven Checkstyle and PMD plugins but now directly embed Checkstyle and PMD libraries.

To find out more about Sonar 2.2 and the 63 issues that have been fixed, you can read the release notes or maybe you prefer to download it to give a ride. Have fun !

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Use Sonar to Develop a Quality Feedback Loop into the Build Cycle

By Brian Chaplin on ServerSide, 29 june 2010
The number of business defects in an application tracks with the number of technical defects. More technical defects normally means more business defects. This means that technical defects can be used as a metric for the overall quality of a development approach. Sonar is a great dashboard for tracking code quality at the project and file level. But how can it be used to as part of the daily workflow?

Making the Most of Maven: Nexus, Hudson, Sonar
By Joel Confino, 15 June 2010
Maven is a build tool. I like Maven because it supports dependency management, consistent builds and a modular code base. But if you are just using Maven without using Nexus, Hudson, Sonar you are really missing out on a lot of goodness. Nexus is a Maven repository manager, Hudson is a CI server, and Sonar is a code metrics server.

Google Summer of Code 2010 with Sonar team – first steps
By Evgeny Mandrikov, 7 June 2010
As I promised in previous post, that progress of my work on Google Summer of Code 2010 would be available publicly – here is a brief overview of what was done for Sonar IDE project, what we have now and what expected in nearest future.

The Code Quality game
By Ricki Sickenger, 4 June 2010
Most programmers think they can recognize good code and a lot of them think they produce good code, but the sad truth is that not a lot of programmers actually do. Between time constraints, feature creep, and laziness, programmers hardly ever end up producing super quality code.

Code-Metriken auf dem Prüfstand
By Sandro Ruch, 4 June 2010
Wie lässt sich die Qualität von Code bestimmen? Welche Kriterien sollen dafür hinzugezogen werden? Eine mögliche Antwort könnte sein: “So gut wie die Abnahme-Testresultate des Kunden”…

Changing a project’s artifact id in Sonar
By Oliver Gierke, 2 Jun 2010
Sonar is a great tool to take care of code quality in your software projects. I use it heavily to monitor the open source projects I am involved with. When working on getting Hades published into Maven central I had to polish it’s pom.xml and felt the need to align the parent project’s artifact to our chosen OSGi compatible package notation for artifacts

Code Quality Management Tool Sonar Provides Design and Architecture Metrics
By Srini Penchikala on InfoQ, 1 June 2010
The new version of open source code quality management tool Sonar provides design and architecture metrics. Sonar 2.0 introduced the analysis of design, architecture and object-oriented metrics for Java applications. And Sonar 2.1 version, which was released recently, supports the detection of unused methods.

It has now been more than ten years since Kent Beck and Martin Fowler started to talk about Continuous Integration. At that time, it was hard to believe this practice would have such an impact on our daily work and would be so much adopted in the world of software development. Today, we at SonarSource but also in many places, can simply not imagine to go back and work without Continuous Integration.

Here is what can be read about Continuous Integration on Wikipedia :
Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.

The ultimate goal of Continuous is to be able to fire any type of release at any time with minimal risk whether it is a Milestone, Release Candidate or GA : quality requirements become a must-have and no more a nice-to-have. Let’s review which requirements are correctly covered by continuous integration environments today :

• Anybody must be able to build the project from any place and at anytime.
• Every Unit Tests must be executed during the Continuous Integration build.
• Every Unit Tests must pass during the Continuous Integration build.
• The output of the Continuous Integration build is a package ready to ship.
• When one of the above requirement is violated nothing is more important for the team than fixing it.

This is a really a good starting point but does not sound sufficient to talk about total quality . What’s about those other source code quality requirements ?

• Any new code should come with corresponding unit tests (regardless of previous state in code coverage).
• New methods must not have a complexity higher than a defined threshold.
• No cycle between packages must be added.
• No duplication blocks must be added.
• No violation to coding standard must be added.
• No call to deprecated methods should be added.
• …

More generally, those requirements are about keeping overall technical debt under control and only let it increase consciously (see the Technical Debt Quadrant) : this is the concept of Continuous Inspection. This concept seems to have appeared around five years ago (see this IBM Article) and has been recently described and defined (see DZone Refcards 87 about Continuous Integration and Continuous Inspection, see book “Continuous Integration : Improving Software Quality and Reducing Risk” ) but is still an emerging concept as was Continuous Integration ten years ago.

Continuous Inspection requires a tool to automate data collection, to report on measures and to highlight hot spots and defects. Sonar is currently the leading “all-in-one” Continuous Inspection engine. A Continuous Inspection engine can be seen as an Information Radiator dedicated to make the source code quality information available at anytime to every stakeholder. Transparency is certainly one of the main reason why Open Source Software is most of the time of better quality than Close Source Software. A developer writing a new piece of code should always think about the next person/team who will maintain it : Continuous Inspection helps to never forget this golden rule.

But of course, Continuous Inspection only comes after Continuous Integration is solidly implemented : this is the next maturity level and this maturity level can be implemented with Sonar.

The Sonar Team is very proud to announce the availability of the first version of the Sonar Eclipse plugin. This plugin is part of the Sonar IDE Project. This first version comes just few a weeks after the release of the Sonar IntelliJ IDEA plugin. The project has 2 active contributors : Jérémie and myself.

The work has been greatly facilitated by the good feedback we received from the Sonar community on the release candidate version. It is going to be followed by new ones in the upcoming weeks/months (see My proposal for GSoC (Google Summer of Code) 2010).

This version 0.1 only displays violations. Duplicated blocks, code coverage and commented out lines of code will be added later. As for the Sonar IntelliJ IDEA plugin, source code is decorated on the fly with information provided by the Sonar web server.

As usual for releases, let’s go through screenshots to discover this new functionality and how it can be used in your daily work to track violations. Enjoy !

Configuration

By default, the plugin tries to reach a local Sonar web server on port 9000 to get violations. But it is possible to define different and several Sonar web servers to use in the Eclipse global preferences :

For instance, for Open Source projects available in Nemo, the configuration would be :

Once, the Sonar web server to be used has been configured, the next step is to activate the Sonar plugin on a given project. If you use m2eclipse, there is nothing to do as the groupId and artifactId of your project are automatically configured. Nevertheless, you may want to change the default Sonar server to use :

Source code decoration

Then you just have to open the java file you want to work on and violations are displayed with markers (on the left-hand side) :

Global source code Inspection

To start hunting violations on the overall project, you can use the Problems View :

Go to Sonar

At any time you can jump onto the Sonar Web dashboard directly from the IDE, to get information that is not yet available in the Sonar Eclipse plugin :

Navigator

Sonar Server Navigator allows you to browse all available projects in a specified Sonar server :

Roadmap

Next version 0.2 will allow to visualize duplicated blocks, code coverage, … directly inside Eclipse, so stay tuned.

To give it a try, you can add it to your favourites in Eclipse Marketplace or install directly using update-site. For more information you can visit Sonar IDE site.

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Developers dashboard : Mash-up activity streams from Jira, Sonar and Hudson
By exoPlatform, 21 May 2010
We are going to build a space in exo social to follow the development of a software. We are going to take as an example the development of eXo Social. We want to integrate the 3 following things: Our task manager – Jira, our code quality tool – Sonar and our building system – Hudson.

Coding Standards with Sonar, Maven and Intellij IDEA
By Mike Nash, 18 May 2010
One of the ways to ensure quality in a software project is to find a set of coding standards that your team can agree on then put automated checks in place to ensure they are adhered to. In this post I’d like to take a very small example of such a stanard, and show how you can use several different tools to help ensure and measure compliance.

Sonar Cobol Plugin released
By SonarSource, 17 May 2010
We are happy to announce the release of the Sonar Cobol Plugin. SonarSource has developed its own state of the art Cobol parser and packaged it as a Sonar Plugin. It allows to perform objective and automated Cobol code reviews against pre-defined or homemade coding best practices.

Passing Hudson BUILD_NUMBER to Sonar Plugin
By arensa, 17 May 2010
Sonar is a great source code analysis tool that integrates through its plugin neatly into the Hudson continuous integration server. One major feature of Sonar is the module called “Time machine” where you can review the progress of the quality metrics for your project over time.

Obeo et SonarSource annoncent la sortie du plugin Sonar1.0 pour VisualBasic 6
By Programmez!, 12 May 2010
Les deux sociétés ont décidé de combiner leur savoir-faire afin de fournir une solution permettant d’analyser automatiquement la qualité du code d’applications VisualBasic 6.

The perfect agile test management tool
By Gojko Adzic, 4 May 2010
David Evans and I facilitated a session on designing a killer agile test management tool last week at the UK Test Management Forum, with the goal of learning what are the biggest currently unsolved problems for agile teams in the area of testing at the moment. So for any tool vendors our there, here are the ideas.

First build of JTheque with Sonar 2.0
By Baptiste Wicht, 2 May 2010
This week-end I updated the version of Sonar to the new version 2.0 and migrated it from Tomcat 5.5 to Tomcat 6.0. I waited until now for the plugins I use to be compatible.

An IntelliJ IDEA Plugin for Sonar
By Evgeny Mandrikov, 1 May 2010
The Sonar Team is very proud to announce the release of a first version of a Sonar plugin for IntelliJ IDEA. Sonar (http://sonar.codehaus.org) is an open-source Code Quality Management Platform based on many well known analysis tools like Checkstyle, PMD, Findbugs, Cobertura, …

Sonar: Understanding your codebase
By Mark Thomas, 29 March 2010
Large code bases can be difficult to understand, particularly for a new joiner to a team. Reading code is a great way to get the detail, but getting a high-level view can sometimes be hard. There are a range of open source tools that can provide Information about code coverage, design attributes and complexity, but it is often hard…

Java Build Server
By Manuel Küblböck, 23 January 2010
In my last Java project, I set up a build server with Continuous Integration (CI) capability. I am a big fan of Test Driven Development (TDD) and I quite enjoyed Hudson telling us right away when someone checked in code that broke the build. It just gives you so much more confidence in your code and keeps it releasable at all times. In addition, we used Sonar to measure the quality of our code.

Up to version 2.1, Sonar was relying only on external coding rules engines such as Checkstyle, PMD and Findbugs to report violations on Java applications. But since version 2.1, Sonar also provides its own rules engine to work on Java dependencies. This rules engine is based on Squid and three rules are currently available :

Squid provides an easy to use visitor pattern to be able to visit dependencies between methods, fields, classes and packages. This visitor pattern has been used in Sonar 2.0 to calculate Object Oriented metrics like LCOM4, RFC, DIT, NOC, … and has been reused in Sonar 2.1 to implement this new rules engine.

Here is a description of the three new rules :

• Use of deprecated method : Once deprecated, a method should no longer be used as it means that the method might be removed one day; it might also mean its usage is inefficient or does not enable to benefit from certain features. Using a deprecated method is a sort of technical debt that must be repaid earlier rather than later. The rule detects calls to deprecated methods not only inside but also outside the project. It means that you can track usage of deprecated methods on Java API or any other external libraries. Here is an example of violation :
  
• Unused protected method or Unused private method : Protected or private methods that are never used by any classes in the same project are strongly suspected to be dead code. Dead code means unnecessary, inoperative code that should be removed. This helps in maintenance by decreasing the maintained code size, making it easier to understand the program. Protected methods that override a method from a parent class are not considered as dead code as those methods are most often used through polymorphism.

To support those new functionality, a new Open Source library called sonar-check-api has been added in the Sonar toolbox. This library offers a mechanism to describe the rule : title, description, default priority, ISO category… For Checkstyle, PMD and Findbugs, an XML file is used to provide such description but this library allows use of java annotations to embed the description inside the rule. Here is an example of use with the new “Use of deprecated method” rule :

Have fun with those three new rules while waiting for new ones like a rule to define the architecture layering :)