By David Racodon on April 26, 2013 » tags customize, dashboard, filter, functionality »
2 comments
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 »
By David Racodon on October 30, 2012 » tags access control, functionality, security »
no comments
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 »
By Evgeny Mandrikov on February 29, 2012 » tags functionality, pmd, Sonar CPD »
4 comments
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 »
By Freddy Mallet on February 16, 2011 » tags continuous inspection, functionality, languages, platform »
13 comments
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 »
By Freddy Mallet on October 12, 2010 » tags functionality »
5 comments
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 »
By Freddy Mallet on May 26, 2010 » tags dependencies, functionality, squid »
11 comments
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 »
By Freddy Mallet on April 8, 2010 » tags design, functionality »
10 comments
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 »
By Olivier Gaudin on March 31, 2010 » tags functionality, platform »
no comments
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 »
By Freddy Mallet on March 17, 2010 » tags design, functionality »
7 comments
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 »