Continuous integration (CI) has become a centerpiece of software development lifecycle. Since Sonar is implemented as a maven plugin, it can be easily integrated with any CI engine : the engine acts as the scheduler for Sonar’s daily runs. You can even imagine to use the well known but a bit outdated cron scheduler to launch the maven goal “mvn org.codehaus.sonar:sonar-maven-plugin:1.4.2:sonar” on each project you want to analyse.
At this point in time, you are probably wondering : ok, but why would I need a plugin to integrate Sonar with Hudson, the very popular, open source and easy to use CI engine ? Is it possible to get an even more seamless integration ?
In fact, when you face a real enterprise context, you need to configure your setting.xml file by hand on your integration machine and copy/paste the Sonar maven goal for each project under control : 10, 50, 100, 200 times … Life will be easier if you can :
- Prevent edition of the setting.xml file and directly edit and view the Sonar configuration from Hudson
- Define the Sonar maven goal only once and use it as often as often as you want
We’ve developed a Hudson plugin to provide those two missing features. All configuration is done online and is shared across projects, you can enable/disable Sonar analysis in one click for all your projects. Obviously, you still can override Sonar parameters at the project level. Imagine for instance, on a given project you don’t want to import and display source code through Sonar interface for security reason (SONAR-306).
subscribe 
subscribe
Hi, on http://hudson.gotdns.com/wiki/display/HUDSON/Sonar+plugin it says: “We recommend to execute Sonar at the most on nightly builds. It’s useless to activate it on continuous builds.” If I understand this correctly, it means I shouldn’t execute Sonar’s maven plugin on every commit a developer makes in Subversion, but I should do it every 24 hours at most?
Please, can you specify the reason why this is.
Thanks a million
Bye
By juancarlos on December 29, 2008 at 6:17 am
Hello,
You can run as many analysis as you wish. However, although Sonar will keep all the analysis done during the day, the reporting interface will only show one analysis per day. Therefore, doing more that one analysis will not be of any use within Sonar. Further more, I don’t think it really makes sens to look at the code quality after every commit, especially if you are committing several times a day.
Going a little bit further, when you have installed and configured Sonar, what you are generally interested in (there might be exceptions) is looking at evolutions and trends. Therefore, to monitor this, a weekly analysis is generally the most appropriate on a fairly active project.
Hope this clarifies.
Olivier
By Olivier Gaudin on December 30, 2008 at 11:51 am
A really useful feature IMHO would be to perform an analysis after each commit and use the comparison against the previous commit to increment/decrement a tally of stats for the committer.
This would enable a team to quickly identify those developers that need mentoring and in which areas the mentoring should focus.
By William Ferguson on January 9, 2009 at 1:11 am
Good idea William !
What would be great is to :
- retrieve which files and which lines in those files have been added or modified
- launch static analysis (checkstyle, pmd and findbugs) and dynamic analysis (see last clover feature : Test optimization) only on those files to drastically reduce the quality analysis time
- push all the collected data into Sonar and report what you want
I don’t know if Hudson API provides a way to easily get which lines have been changed in a file ?
By Freddy Mallet on January 10, 2009 at 12:05 am
So close, but sonar can’t seem to find artifacts from the sonar repo
[INFO] Failed to resolve artifact.
Missing:
———-
1) org.codehaus.sonar.runtime.plugins:parent:pom:20090109135100
Path to dependency:
1) org.codehaus.sonar:sonar-core-maven-plugin:maven-plugin:1.5.1
2) org.codehaus.sonar.runtime.plugins:parent:pom:20090109135100
2) org.codehaus.sonar.runtime.jdbc-driver:parent:pom:20090109135100
Path to dependency:
1) org.codehaus.sonar:sonar-core-maven-plugin:maven-plugin:1.5.1
2) org.codehaus.sonar.runtime.jdbc-driver:parent:pom:20090109135100
———-
2 required artifacts are missing.
for artifact:
org.codehaus.sonar:sonar-core-maven-plugin:maven-plugin:1.5.1
from the specified remote repositories:
central (http://repository.codehaus.org),
sonar (http://localhost:9000/deploy/maven)
By Morgan on January 10, 2009 at 3:55 am
Hi Morgan, can you switch to the Sonar mailing list to discuss your issue ? Seems like you use a maven mirror configuration or something like that.
By Freddy Mallet on January 12, 2009 at 1:13 am
Is sonar usable for C++ projects. All the users listed at http://nemo.sonar.codehaus.org seem to be java projects. The tools bundled by sonar also seem to be for java.
By Shiv on February 1, 2009 at 2:53 am
Sonar isn’t yet bundled with C++ code analyzers.
By Freddy Mallet on February 1, 2009 at 7:53 pm
You say :“We recommend to execute Sonar at the most on nightly builds. It’s useless to activate it on continuous builds.”
but how to do that with your plugin? In Hudson, what can I configure is the scheduling to track scm changes or a personal scheduling but this is always the same build goal that is executed, but I don’t want to execute sonar when scm change!
An idea?
By Francky on February 23, 2009 at 3:42 pm
You need to setup 2 jobs in Hudson. One for your continuous integration that is gonna poll the scm. The other one with a personal scheduling for Sonar execution.
By Olivier Gaudin on February 23, 2009 at 7:00 pm
Hudson plugin 1.0 is out with many improvements : master/slave mode, i18n (currently English/French), easier configuration and some advanced parameters. It needs Hudson 1.306+ and Sonar 1.8+.
By Simon Brandhof on May 20, 2009 at 5:44 pm
[...] objective was reach last September with the release of Hudson Sonar plugin version 0.2. Since then, we have used the plugin and have been able to increase without big effort the number [...]
By Sonar » Hudson Sonar plugin 1.0 : to industrialize the ultimate build system on June 3, 2009 at 12:48 pm
what should I do if I have more than one source directory?
By Fernando on September 4, 2009 at 2:27 pm
If you use latest version 1.1. of the Hudson plugin, this feature is available :
http://jira.codehaus.org/browse/SONARPLUGINS-15
By Freddy Mallet on September 5, 2009 at 8:57 am
You write: “There is an unknown but yet useful Sonar functionality which allows you to analyze any java projects even if they don’t use Maven (perhaps you’re still using Ant or don’t use a build framework at all). Nevertheless, in that case you need to write by hands a short pom.xml file to provide to Sonar several mandatory parameters.This last tedious step has gone with version 0.2 of the plugin.” Does that mean that I can start sonar without any maven installation?
By Felix Ziesel on October 28, 2009 at 12:14 pm
It means that when you are using Hudson, you can start Sonar analysis without touching Maven at all. Hudson is going to handle it for you.
By Olivier Gaudin on October 28, 2009 at 11:18 pm
While this is great (thanks!) it doesn’t allow to specify that the coverage reports should be coming from emma. I work around this by setting system properties (sonar.core.codeCoveragePlugin and sonar.emma.reportPath) in the main hudson config, but it ain’t so nice.
By Ulli on December 5, 2009 at 10:16 pm
This is correct that it does not allow you to specify that the coverage reports should be coming from emma. Two comments though :
1. Emma coverage is not part of Sonar core which is why the sonar.emma.reportPath was not included originally in the Hudson plugin. Could you create a Jira issue to include it ?
2. Instead of using the sonar.core.codeCoveragePlugin, wouldn’t it make more sense to set it up in the Sonar configuration section, either globally or per project ?
By Olivier Gaudin on December 6, 2009 at 6:05 pm
Has anyone successfully used the Hudson plugin with Sonar and the Sonar MetriC++ plugin?
I’m able to trigger the Sonar analysis from Hudson, but the Sonar results never show any violations, duplicate code, etc.
By Craig on December 16, 2009 at 5:51 pm
Hi Craig, feel free to send an email to the Sonar mailing list (http://sonar.codehaus.org/support/) and attach to this email your Maven log.
Thanks
By Freddy Mallet on December 16, 2009 at 9:58 pm
I’m using the 1.1 version of the plugin with Hudson 1.340, I’m not sure how it’s supposed to be set up.
For “Sonar Installation”, the only choice I have is “default”, should there be something else to choose from?
For “Sonar maven runtime”, again the only choice is default. Since we using ANT and the “NOT built with maven” box is checked, I’m not sure what this thing is doing here at all.
Source directory. This is relative to what? Is it the workspace?
BTW, clicking on the question mark brings up a 404 error.
Thanks in advance.
By Andy on January 28, 2010 at 8:35 pm
Andy,
Might be easier to switch to the mailing list to discuss all this.
For “Sonar Installation”, you could have several instances of Sonar and in that case and in that case more entries would appear. Same thing for Maven. Sonar analyzer being a maven plugin you need a maven installation in all cases.
Source directory is the directory where the root of the sources is located.
Which of the question mark is showing a 404 ?
Olivier
By Olivier Gaudin on January 31, 2010 at 2:14 pm