On my local machine for my project trying to see the code quality related issues that sonarqube shows.
Using eclipse IDE.
Installed sonarlint plugin and I am able to see most of the issues that I see in the sonarqube for my project.
But, don’t see issues related to duplicate code etc
From what I see on internet sonarqube uses other third party tools like PMD, checksyle, findbugs to show other issues apart from what sonarlint shows.
Who usually provide the xml rulesets for PMD, Checkstyle etc in the company? Is it the sonar team or the architecture team? or the project team leads create one and provide it to the team.
At the time of this writing, SonarLint runs analyses file by file,
so it cannot display errors involving multiple files, such as:
Duplications
Test coverage
Package-level issues (package-info.java is missing, etc)
Furthermore, it only shows issues from SonarSource analyzers,
third party analyzers such as PMD and checkstyle are excluded.
Finally, it will show the same issues as you see in SonarQube in connected mode.
Otherwise, in standalone mode,
it uses the default quality profile (= set of rules),
as defined by its embedded analyzers,
which may slightly vary depending on their version.
The differences that you see between SonarLint and SonarQube will come down to one or more of the reasons as explained above.
Who usually provide the xml rulesets for PMD, Checkstyle etc in the company? Is it the sonar team or the architecture team? or the project team leads create one and provide it to the team.
That depends on the company, and any answer to this would be subjective.
Related
I have pretty standard Maven multi-modules project (with JUnit, Arquillian and Selenium tests). I have Sonar 6.2 installed on a server. And on my project on Sonar the Code Coverage metric indicates 0.0%. But I know it's wrong as I do have some test coverage.
I found this Generic Test Data documentation page that explains that since 6.2 Sonar is supporting code coverage out of the box and that I have to pass a comma-delimited list of report paths to a parameter sonar.coverageReportPaths (I guess provided either in my pom or in command line).
I'm fine with that. But I cannot find out an example on how to setup this for a pretty classical Java project. What kind of file do I need to give in the list ? The relative paths to each of my Surefire/Failsafe reports ? Do I need to generate Jacoco reports in addition ? Can I give a "generic" path like report.xml if all of my reports have the same name ?
For standard Java project is it probably the easiest to use JaCoCo to generate coverage data and then feed it to SonarJava (SonarQube's plugin to analyze Java code). You can find documentation here
https://docs.sonarqube.org/display/PLUG/Code+Coverage+by+Unit+Tests+for+Java+Project
You might find mentions of separation between unit tests and integration tests, this has been deprecated and now there is only single kind of coverage.
Don't hesitate to reach out to mailing list or ask question if something is not clear, we are in the process of improving this documentation.
I have just updated SonarQube from 5.3 to 5.6.3
Running a first analysis I realized that the rule squid:CycleBetweenPackages has been removed from the "Sonar way with Findbugs" Java quality profile.
Is there a specific reason this rule has been removed from the default profile? If I add it manually to the quality profile, it is ignored and not added to the ruleset.
Well there is indeed a pretty good reason, this rule was dropped in version 4.0 of the java plugin as mentioned by this ticket : https://jira.sonarsource.com/browse/SONARJAVA-1717
Main reason to remove that rule is that it is out of scope of the core feature SonarQube Analyzers aim to provide.
My co-worker found this morning that compiling a project with Cobertura enabled changes the sonar results on the same project.
On this particular project we ran a build with sonar:sonar and then ran it again with cobertura:cobertura sonar:sonar.
The sonar results in the comparison are now showing that without Cobertura we have 7/78/153/24/0 violations of the 5 severities, but with Cobertura it changes to 7/81/94/24/0, and in particular finds 3 new critical violations and 15 new major violations that aren't found without Cobertura.
One of the biggest changes is that without Cobertura there are 60 violations of the rule against empty methods (many of them constructors) and with Cobertura only 3 of those are reported.
If Cobertura only prevented violations from being found we could run the two independently, but since some violations are only found with Cobertura enabled it seems like we would have to do two separate Sonar analyses.
Is this a known interaction? Is there any workaround other than doing Cobertura and Sonar in separate builds? And using both sets of results to get the best data?
Based on the comment you made let me explain what it seems to be happening:
You are using FindBugs via SonarQube (rules you are mentioning are findbugs rules)
First let's think about the two tools involved here and how they work (roughly) :
FindBugs : it is a static analysis tool based on bytecode : it will read bytecode and raise issue when it detects bad pattern.
Cobertura : Coverage tool : how does this work ? it instruments the bytecode to place probes and when tests are run keep track of which probes where hit or not.
Then you can understand where the issue might be : FindBugs ends up analyzing the bytecode instrumented by Cobertura. That would explain why you have some new issues and why some of the empty methods issues are removed when analyzing with cobertura.
To avoid this issue you have to be sure your bytecode files are not instrumented when you analyze them with FindBugs but (disclaimer, I develop the sonar java plugin so I might be a little biased here ;) ) I would recommend you to stop using FindBugs in favor of the SonarQube Java Analyzer which won't have this issue as its analyzer approach things slightly differently (see this blog post about that)
User error. :-(
It turns out that the user had run a mvn clean prior to running the sonar:sonar with cobertura, so as implied by benzonico, the findbugs rules that have to analyze compiled code didn't run. Only the rules that are run on source code, like the java plugin, generated results. That's why we were missing a bunch of rules and results.
We still have inconsistencies between Bamboo and manual builds, but that would be a topic for a separate post.
I’d like to ask for help. I installed the plugin and successfully added the SonarQube server. I upgraded to version 4.1.2. I use IntelliJ IDEA 13.0.2.
I also successfully associated the project and inspection warnings appeared. But when I fix the issue the status is not updated.
How to synchronize ?
I also run inspection by name ‘SonarQube issues’.
Nevertheless after running the inspection the warnings are also there, where the code was fixed. It seems to me the synchronization somehow fails.
Any idea, what todo, please?
What I had done in my situation.
Installed SonarQube 4.4.
Installed IntelliJ 13.1.4b (the same history was with 13.0.4).
Configured SonarQube intelliJ plugin (not community provided one but plugin from SonarSource). All instructions are under the link on Wiki.
Attached to Sonar project. Every step just as SonarSource recommends.
This gave me mapping from Sonar onto source code. But it does not update when I simply fix the issue. But if I fix issues I then re-post project onto Sonar through mvn sonar:sonar and this gives me updated picture next time I run inspection through sonarqube plugin.
But this is not 100% what is wanted. But definitely better than nothing. Also I have imported Sonar rules through QAPlug - this is far less useful. But notable faster.
Overall this configuration allows me to make what is needed but I'd like to receive real incremental processing without publishing local changes onto Sonar server.
Give a try to the SonarQube IntelliJ Community Plugin, it is made for fixing issues detected by jenkins on the local dev machine. Different then the official plugin you will need to do more configuration by yourself, but it gives you also the freedom to specify your local analysis script like you need.
What you need to do:
configure the plugin
setup sonar server
setup local analysis script
Afterwards you can run SonarQube (new issues) inspection, this will run the script and show the results in the Intellij. If you are fixing issues, you can just rerun the inspection from inside the inspections results tool window. This will rerun the script and show new results.
see also: https://github.com/sonar-intellij-plugin/sonar-intellij-plugin
NetBeans is by default better than Eclipse (imho) in detecting code smells, but the Unnecessary Code Detector for Eclipse seems to find more dead code and code that should be improved. Is there something comparable for NetBeans or is there a Maven plug-in?
Not a direct answer to your question, but this might be interesting: Here is a set of plugins for NetBeans to integrate tools like FindBugs, PMD and CheckStyle into NetBeans.
Those tools are static code analysis tools: they look at your source code and give you information about possible error-prone constructs, possible bugs etc. and can most likely also find unused code.
Take a look at this plugin: dead code detector.
It is a sort of proof-of-concept plugin build on Emeric Vernat's DCD project.
ps. there is also a feature request [Bug 181458] on which you can vote to get this feature in Netbeans out-of-the-box :-)
The ucdetector is strictly limited to eclipse and can't be used in a different environment. So if you wanted to use it, you'd have to install a basic eclipse somewhere with projects pointing to your source directories and use it for unused code detection only.
Another way to identify unused code is instrumenting the (live) application, run it for a while and analyse the logs. Usual tools are Emma, Cobertura, and Clover.
Couldn't resist - detecting code smells with eclipse...
Checkstyle plugin for eclipse
PMD integration for eclipse
findbugs integration for eclipse