I've just updated my local Sonar installation to 3.7 from 3.3. Previously, I've analyzed projects with Sonar using the Maven plugin (clean install sonar:sonar). On this old setup, everything works like a charm, more specifically Checkstyle, Findbugs, PMD violations were added to the Sonar analysis.
Since the upgrade, I'm not getting any Checkstyle, Findbugs, PMD results (violations count == 0, which I cannot imagine to be true as a local Eclipse PMD run results in quite some violations to solve).
During upgrade of Sonar 3.7, I had to remove the Checkstyle, PMD, findbugs plugins on Sonar, as they were included in the Java ecosystem (according to the docs).
Am I missing something, or can you give me any pointers to enable analysis?
Cheers,
Jeroen
You must be missing some jars from the Java Ecosystem. The zip file can be found on http://docs.codehaus.org/display/SONAR/Java+Ecosystem
Related
I'm using a clone of an app which uses FindBugs, PMD, CheckStyle plugins.
But now, i've made some changes which makes minimum Gradle version to 6.5 and now i'm getting this error:
Plugin with id 'findbugs' not found.
As i read, the findbugs is deprecated for gradle 5.0+ .
Now, how can i remove the usage of these 3 plugins in this clone? Or how can i replace it(i think SpotBugs is the new version of it!)
Or how to solve this error?
Remove Findbugs and Add Spotbugs in your project.
You don't need to remove PMD and CheckStyle. They are working perfectly.
Only change is of Findbugs.
I'm using Gradle 4.4 on my Java project with JaCoCo 0.8.0, and Sonar with SonarJava 5.0.1.
I have a class annotated with lombok's #Value and #Builder.
My JaCoCo config in build.gradle looks like this:
jacoco {
toolVersion = "0.8.0"
reportsDir = file("$buildDir/reports/jacoco")
}
jacocoTestReport.doFirst{
classDirectories = files("buildDir/classes")
}
task jacocoReport(type: JacocoReport){
sourceSets sourceSets.main
executionData test, integrationTest
}
Also, I have lombok.confi file, with property lombok.addLombokGeneratedAnnotation = true, and generated stuff does actually have #lombok.Generated annotation in build/classes.
However, the coverage on Sonar is still low. It reports a ton of conditions and lines to cover.
As stated in announcement of release of JaCoCo version 0.8.0:
Please Note
Tools that directly read exec files (which is not a final report) and embed JaCoCo for generation of report will provide filtering functionality only after they updated to this version of JaCoCo.
So please follow/wait/etc respective vendors such as
SonarQube - https://jira.sonarsource.com/browse/SONARJAVA-2608
Reports generated by corresponding version (0.8.0) of integrations developed as part of JaCoCo project by us (Ant Tasks, Maven Plugin and Command Line Interface) provide filtering functionality.
With Gradle JaCoCo Plugin you can select both runtime and version for "JaCoCoReport" task using "toolVersion" - https://docs.gradle.org/current/userguide/jacoco_plugin.html
This is also stated in JaCoCo changelog:
Note: Tools that directly read exec files and embed JaCoCo for this (such as SonarQube or Jenkins) will provide filtering functionality only after they updated to this version of JaCoCo.
As of today (29 Jan 2018) fix for https://jira.sonarsource.com/browse/SONARJAVA-2608 is supposed to be in not yet released SonarJava plugin version 5.1.
From all the above: report generated by Gradle should already be filtered, report generated by SonarQube will be filtered after upgrade of SonarJava.
Apart from configuring lombok, I also had to tell sonar scanner where to find the dependencies. Was the only way to get rid of the "Unused private fields should be removed" message in SonarQube.
I followed instructions from this site: https://netwolfuk.wordpress.com/2017/10/29/maven-sonarqube-jacoco-lombok-and-teamcity/
It boils down to:
Tell maven to copy its dependencies to somewhere Sonar can find them. This is simple as adding:
dependency:copy-dependencies
Add the following to the sonar build step:
-Dsonar.java.libraries=target/dependency/*.jar
New to Sonar. Am comfortable with checkstyle and jacoco.
What I am exploring is in a a gradle project, give developers ability to run style checks and code coverage reports locally, but then use bamboo to publish reports in sonar.
Is this a viable option ? I can see that jacoco plugin and sonar plugin can be in the same build.gradle and so guessing that jacoco reports can be got from sonar. However am unsure how checkstyle integration works. From what I see, I can add a checkstyle plugin to sonar, but then I will have to define rules in SonarQube. I will like to keep checkstyle configuration locally so developers can run a local check before commiting code.
Bear with me if the questions are naive.
Your goal: enable developers to run the same set of rules locally that are applied in a SonarQube scan.
The means: SonarLint offers a "connected mode" for IntelliJ, Eclipse, and Visual Studio. Assuming you're using the SonarQube Analyzers, they'll get on-the-fly checking as they code using the same rule set locally as is applied in an analysis. If the profile changes on the server, it can be manually re-synchronized in the IDE.
The hitch: to make this work seamlessly, you should look at replacing your Checkstyle rules with the ones offered by the SonarQube Analyzer for Java (i.e. the Java plugin). Almost all of the "valuable" rules from Checkstyle have been replaced in the Java plugin.
I'm using sonar with jenkins for continues integration and code analysis. I learned that sonar by default includes Checkstyle, FindBugs, JaCoCo, PMD altogether, so we don't need to configure any of the above plugins to a project. But when I check the Quality Profile, there are two profiles named as Sonar way with 113 rules and Sonar way with Findbugs with 516. What does mean by there profiles? Why they have different rules?
And, I have a requirement like, for some project, I need to configure Checkstyle only for another project may be Checkstyle with PMD, etc. Is it possible to do that?
Sonar works by parsing the output of the external tools like Checkstyle, FindBugs, PMD, etc. In short you don't need to configure the plugins, but you can specify the way Sonar reacts to violations in your code found by the plugins.
With Quality profile you can set the rules for your project and modify them for your needs, e.g. line length by default is 80, but you can extend it for your project to 120 characters. If your coding style doesn't care about line length you can disable the rule.
Two default quality profiles gives you an option to decide to build the project with or without Findbugs, which means that your build will or will not run Findbug tool. Findbug provides wider set of rules, but will slow down your build.
To set a specific rules to specific projects you can check here
We build our projects with ant and happy with it.
The other day, I wished to give Sonar a try only to discover that it requires me to have maven. So, I guess I need some kind of pom.xml somewhere in my project.
There are three things I wish to avoid:
Learn maven right now (in general I may want to, but not now)
Migrate to maven from ant
Maintain two build scripts - one for ant and the other for maven.
Is it possible to have this pom.xml as minimal as possible and yet to be able to analyze the project with Sonar?
Thanks.
P.S.
Less demanding Sonar alternatives are welcome as well.
as requested, putting this as an answer:
SONAR comes with an ANT task
Also look at this.
Sonar version 2.6 introduced an ANT task for running Sonar.
Code coverage reporting requires additional work. See the following answer:
SONAR - Measure Code Coverage using Cobertura