Customizing Sonar to Fit Your Needs

Sonar is a super-radiator for code quality and as such, you can expect it brings value to all stakeholders in a development group. To achieve this, Sonar must be able to show only relevant information in a certain context and shut off the noise to facilitate investigation and decision making. In this post, I will show how to customize Sonar to fit your needs by:

  • creating filters that choose components and metrics to report on
  • building your own widgets and dashboards
  • selecting default dashboards displayed
  • using the notification services and stay tuned

To start customizing Sonar, you first need to log in.

Read the rest of this page »

Access Control Management in Sonar

When used out-of-the-box, Sonar is a radiator for code quality continuously accessible by everyone. But of course, there are situations in which adding access control is necessary. Access control management in Sonar exists since version 1.12 (Nov. 2011) and covers most use cases:

  • securing an instance by making authentication mandatory, for example to expose it to the internet
  • isolating from each other the access to projects
  • protecting the source code of a strategic project
  • delegating project administration to a key user

Read the rest of this page »

Manage Duplicated Code with Sonar

If you use Sonar already, I am sure that you know already the worse of all 7 developer’s deadly sins:


And if you don’t, I would assume you know about duplicated / cloned / similar code when you talk about quality of code and that you have heard of tools such PMD CPD or Simian.

But why does copy paste matters from a code quality point of view? How can you benefit from Sonar to improve this? Let’s try to figure this out.

Read the rest of this page »

What is coming up for Sonar in 2011 ?

After an initial attempt that ended up posting on what was accomplished last year, time has now come to discuss the plans for Sonar in 2011 and the associated roadmap !

In 2010, Sonar has progressively become a “must have in software factories” as are already Jenkins, Jira, Nexus or Subversion for instance. With Sonar, a quality platform can now be considered as a commodity which can be installed and used by everybody with only little investment whether it is time or money. We will still focus our effort in 2011 to increase the value of the platform and make teams capable of continuously assessing and reimbursing their technical debt even easily than today.

Read the rest of this page »

Bridging Internal and External Quality with Sonar

A few weeks ago, Evgeny described how Sonar can be used with its JaCoCo plugin to measure code coverage by Integration Tests. By adding this new feature to Sonar, Evgeny has actually done more than closing the most voted issue in Jira at the time : he has made a first baby step towards closing some gaps that exist in the world of Software Quality.

Read the rest of this page »

The new “Filters” functionality added in Sonar 2.2

Prior to Sonar 2.2, the home page was simply the list of projects under quality control. Beyond the fact that it did not add much value to the platform, it was unreadable with more than 100 projects and could not even load with more than 800 projects ! This is why we switched the default Sonar home page from an “All Projects” service to a “Filters” service in Sonar 2.2.

Read the rest of this page »

Detect Dead Code and Calls to Deprecated Methods with Sonar Squid

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 :

Read the rest of this page »

Clean Up Design at Class Level with Sonar

When learning Object-oriented programming, two of the concepts are fairly difficult to understand and therefore to digest : classes must be loosely coupled and highly cohesive. In today’s post, I am going to explain why this is important and how Sonar can help you evaluating how cohesive are your classes.

A few weeks ago, I started a discussion on how to Fight Back Design Erosion by Breaking Cycles with Sonar in which I mentioned that good design should enable to replace any part of a system by a new piece of code with little pain. The first aspect to look at is really the “macro level”, i.e. packages, to ensure for instance that there are no cycles between packages. But to obtain modularity at any level of the design you also need to consider the “micro level”, i.e. the classes / methods, by keeping it loosely coupled and highly cohesive.

Read the rest of this page »

Sonar Proposals for Google Summer of Code

Codehaus has been officially accepted into Google Summer of Code 2010. Based on the great job done by Ben Walding previous years, we expect that several projects get funded at The Haus this year.
Ben has open a page for Codehaus projects to propose ideas they wish student could pick and develop. We have proposed 3 ideas that we think are interesting challenges for students and a great addition to the Sonar platform :

Read the rest of this page »

Fight Back Design Erosion by Breaking Cycles with Sonar

With version 2.0, Sonar now embarks the seventh and last axis of source code quality : Design & Architecture. The objective of this post is to start discussing what it can be used for and why it is so important.
To know if the design of your software is in a good shape, having a sense of observation and a good memory can most of the time do the trick. No real need to use a tool (whether it is UML diagrams, Sonar…) or to look at source code. If month after month, your software is able to evolve as quickly as the business requires and can handle the changes at a constant cost throughout time, then you can confidently conclude that the design of your application is in a good shape (and believe me, it is fairly unusual in the software development market !). If not, you should focus some attention on design as it is not going to get better over time and will become costly in the medium to long term.
To handle fearlessly upcoming changes, it is key that the software design has great modularity. That is to say, you can replace part of the system by a new piece of code with little pain. Reaching true modularity can only be achieved in a programming environment that has two main capabilities (two dimensions) : ability to assemble pieces of software and ability to recursively split a piece of software. However, these capabilities are necessary but not sufficient.

Read the rest of this page »

Page 1 of 3123