I'm getting started with SonarQube usage for JSF page static analysis[1] in Maven. I'm only really interested in using it in Maven since I don't like the idea to introduce another build command.
After going through Analyzing the source code and the specific Maven guide I gained the impression that the plugin can only be used after downloading, installing/unpacking and starting a SonarQube instance at localhost and specifying the connection information in the plugin declaration in the POM. The plugin configuration parameter confirm that.
While this workflow might have advantages it is painful to use on CI services and the necessity to start a service manually in order to be able to build seems not very user friedly (given the fact that other development tools like Selenium or Arquillian pull entire browser, driver and servers in the background without one single line of configuration). Am I missing something about a separate plugin or configuration which manages an embedded or otherwise temporary instance to perform the analysis with a single plugin declaration?
[1] I'm aware that there're other tools based on XML validation which could do the job, but setting up a much more powerful tools like SonarQube seems to be a more flexible approach which will probably pay off.
You don't have to install SonarQube on your build server, but it is necessary to execute analysis (results will be pushed to it). It means that you have a working server somewhere and next you have to set required parameters:
sonar.host.url (http://localhost:9000 is a default value)
sonar.login and sonar.password (if your SonarQube server is secured)
See all Analysis Parameters.
I've started working with jHipster on a recent project which is a tool you can use to autogenerate the full stack of a REST api application using a Spring Boot back end. Which should save a great deal of time writing boilerplate code...
Unfortunately, at my work we have coding standards to adhere to in the form of a set of CheckStyle rules. Any code that does not adhere to these rules causes the build to fail. What I am experiencing at the moment is that this autogenerated code is failing the CheckStyle rules in a large number of places. Currently I am handling this by manually trawling through the code fixing each of the issues.
I can't help feeling in the back of my mind there must be a better way of doing this e.g.:
Configuring the IDE (intelliJ) to ensure the generated code matches the CheckStyle rules. This is certainly possible when coding directly into the IDE.
Configuring jHipster to be aware of the CheckStyle rules before autogenerating the code.
Running a script afterwards which can automatically fix any CheckStyle failures. (I'm sure this must be doable!)
It would be good to hear if anyone knows what the best way to address this issue might be and if anyone has done something similar in the past.
Suppress violations on all auto-generated files as it is out of your control.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionFilter
If you have auto-generated code inside a file with non-generated code that you maintain manually, use comment suppressions.
http://checkstyle.sourceforge.net/config_filters.html#SuppressionCommentFilter
You shouldn't be styling code you don't write for this exact purpose, you aren't writing it and some utility is and it wasn't built to your style specifications. If you generate the files again, it will undo any manual changes you made.
I'm evaluating SonarQube 5.4 with SonarLint eclipse plugin.
SonarQube as well as the plugin are set up and are running. But now I'm pretty confused how SonarLint is supposed to run in 'connected mode':
SonarLint is connected with SonarQube and is bound to the corresponding project. But some issues are only shown in SonarQube. It was my understanding SonarLint should be able to identify issues like Malicious code vulnerability - May expose internal representation by incorporating reference to mutable object. But it does not. SonarQube does.
When analysing a single file with SonarLint, there are a lot of debug messages in the SonarLint Console like Class not found in resource cache : org/company/project/CommonSuperClass. But even worse: Class not found in resource cache : java/lang/Class. Is it supposed to do that?
We are specifically interested in highlighting the issues introduced by developer. SonarQube is connected our repo and does a nice job in blaming the committer. But it seems there is no way of showing my own issues in sonarlint.
I'd like to run the SonarLint analysis at a time of my choice, so I decided to deactivated "Run SonarLint automatically". But it seems I can only analyze files manually, not packages or projects. Am I missing something again? I do not want to click on every one of my ~2000 files and analyze it by hand.
SonarLint and SonarQube are 2 different products:
You want very fast feedback on the code you are working on to make sure you don't inject issues => SonarLint analyses the files as you open them to write or review code
You want a 360° vision of the quality of your code => SonarQube analyses all the files of your project
The "connected mode" is the bridge between the 2 worlds, and its development is still underway. For instance, we plan to make it possible to see inside SonarLint all the issues found on the project by SonarQube (see and vote for SLE-54).
I have a Maven-based Java webapp that has bunch of unit tests, integration tests, code coverage reports etc and some more technical details.
I would like generate project information which would contain all the above information aggregated in one place so that it could be seen by others.
What's are some of the tools available in order to achieve this?
Remote server upload can be done either via http/dav/scp etc.
You can maintain a roadmap via markdown/apt or other formats.
Current open issues (may be jira) via maven-changes-plugin ?
Technical details such as tools etc. can be documented by the above as well?
Unit tests results can be done via usual maven site generation (surefire reporting) Code coverage via cobertura the old way or via JaCoCo.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What code analysis tools do you use on your Java projects?
I am interested in all kinds
static code analysis tools (FindBugs, PMD, and any others)
code coverage tools (Cobertura, Emma, and any others)
any other instrumentation-based tools
anything else, if I'm missing something
If applicable, also state what build tools you use and how well these tools integrate with both your IDEs and build tools.
If a tool is only available a specific way (as an IDE plugin, or, say, a build tool plugin) that information is also worth noting.
For static analysis tools I often use CPD, PMD, FindBugs, and Checkstyle.
CPD is the PMD "Copy/Paste Detector" tool. I was using PMD for a little while before I noticed the "Finding Duplicated Code" link on the PMD web page.
I'd like to point out that these tools can sometimes be extended beyond their "out-of-the-box" set of rules. And not just because they're open source so that you can rewrite them. Some of these tools come with applications or "hooks" that allow them to be extended. For example, PMD comes with the "designer" tool that allows you to create new rules. Also, Checkstyle has the DescendantToken check that has properties that allow for substantial customization.
I integrate these tools with an Ant-based build. You can follow the link to see my commented configuration.
In addition to the simple integration into the build, I find it helpful to configure the tools to be somewhat "integrated" in a couple of other ways. Namely, report generation and warning suppression uniformity. I'd like to add these aspects to this discussion (which should probably have the "static-analysis" tag also): how are folks configuring these tools to create a "unified" solution? (I've asked this question separately here)
First, for warning reports, I transform the output so that each warning has the simple format:
/absolute-path/filename:line-number:column-number: warning(tool-name): message
This is often called the "Emacs format," but even if you aren't using Emacs, it's a reasonable format for homogenizing reports. For example:
/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.
My warning format transformations are done by my Ant script with Ant filterchains.
The second "integration" that I do is for warning suppression. By default, each tool supports comments or an annotation (or both) that you can place in your code to silence a warning that you want to ignore. But these various warning suppression requests do not have a consistent look which seems somewhat silly. When you're suppressing a warning, you're suppressing a warning, so why not always write "SuppressWarning?"
For example, PMD's default configuration suppresses warning generation on lines of code with the string "NOPMD" in a comment. Also, PMD supports Java's #SuppressWarnings annotation. I configure PMD to use comments containing "SuppressWarning(PMD." instead of NOPMD so that PMD suppressions look alike. I fill in the particular rule that is violated when using the comment style suppression:
// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained
Only the "SuppressWarnings(PMD." part is significant for a comment, but it is consistent with PMD's support for the #SuppressWarning annotation which does recognize individual rule violations by name:
#SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended
Similarly, Checkstyle suppresses warning generation between pairs of comments (no annotation support is provided). By default, comments to turn Checkstyle off and on contain the strings CHECKSTYLE:OFF and CHECKSTYLE:ON, respectively. Changing this configuration (with Checkstyle's "SuppressionCommentFilter") to use the strings "BEGIN SuppressWarnings(CheckStyle." and "END SuppressWarnings(CheckStyle." makes the controls look more like PMD:
// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)
With Checkstyle comments, the particular check violation (HiddenField) is significant because each check has its own "BEGIN/END" comment pair.
FindBugs also supports warning generation suppression with a #SuppressWarnings annotation, so no further configuration is required to achieve some level of uniformity with other tools. Unfortunately, Findbugs has to support a custom #SuppressWarnings annotation because the built-in Java #SuppressWarnings annotation has a SOURCE retention policy which is not strong enough to retain the annotation in the class file where FindBugs needs it. I fully qualify FindBugs warnings suppressions to avoid clashing with Java's #SuppressWarnings annotation:
#edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")
These techniques makes things look reasonably consistent across tools. Note that having each warning suppression contain the string "SuppressWarnings" makes it easy to run a simple search to find all instances for all tools over an entire code base.
I use a combination of Cobertura, Checkstyle, (Ecl)Emma and Findbugs.
EclEmma is an awesome Eclipse plugin that shows the code coverage by coloring the java source in the editor (screenshot) - the coverage is generated by running a JUnit test. This is really useful when you are trying to figure out which lines are covered in a particular class, or if you want to see just which lines are covered by a single test. This is much more user friendly and useful than generating a report and then looking through the report to see which classes have low coverage.
The Checkstyle and Findbugs Eclipse plugins are also useful, they generate warnings in the editor as you type.
Maven2 has report plugins that work with the above tools to generate reports at build time. We use this to get overall project reports, which are more useful when you want aggregate numbers. These are generated by our CI builds, which run using Continuum.
All of the following we use and integrate easiy in both our Maven 2.x builds and Eclipse/RAD 7:
Testing - JUnit/TestNG
Code analysis - FindBugs, PMD
Code coverage - Clover
In addition, in our Maven builds we have:
JDepend
Tag checker (TODO, FIXME, etc)
Furthermore, if you're using Maven 2.x, CodeHaus has a collection of handy Maven plugins in their Mojo project.
Note: Clover has out-of-the-box integration with the Bamboo CI server (since they're both Atlassian products). There are also Bamboo plugins for FindBugs, PMD, and CheckStyle but, as noted, the free Hudson CI server has those too.
I use the static analysis built into IntelliJ IDEA. Perfect integration.
I use the code coverage built into Intellij IDEA (based on EMMA). Again, perfect integration.
This integrated solution is reliable, powerful, and easy-to-use compared to piecing together tools from various vendors.
Checkstyle is another one I've used at a previous company... it's mainly for style checking, but it can do some static analysis too. Also, Clover for code coverage, though be aware it is not a free tool.
We are using FindBugs and Checkstyle as well as Clover for Code Coverage.
I think it's important to have some kind of static analysis, supporting your development. Unfortunately it's still not widely spread that these tools are important.
We use FindBugs and JDepend integrated with Ant. We use JUnit but we're not using any coverage tool.
I'm not using it integrated to Rational Application Developer (the IDE I'm using to develop J2EE applications) because I like how neat it looks when you run javac in the Windows console. :P
I've had good luck with Cobertura. It's a code coverage tool which can be executed via your ant script as part of your normal build and can be integrated into Hudson.
Our team use PMD and Cobertura, actually our projects are maven projects and there is very simple to include plug ins for code analysis. The real question would be for specific project which analysis you need to use, my opinion is that it's you couldn't use the same plugins for each project.
in our project we use Sonar in front of checkstyle, pmd.... together with the CI (Bamboo, Hudson) we get also a nice history of our source quality and what directing we go. I do like Sonar, because you one central tool in the CI Stack that does it for you, and you can easy customize the rules for each project.
Structure 101 is good at code analysis and finding the cyclic package dependencies.
I am looking for many answers to learn about new tools and consolidate this knowledge in a one question/thread, so I doubt there will be 1 true answer to this question.
My answer to my own question is that we use:
Findbugs to look for common errors bad/coding - run from maven, and also integrates easily into Eclipse
Cobertura for our coverage reports - run from maven
Hudson also has a task-scanner plugin that will display a count of your TODO and FIXMEs, as well as show where they are in the source files.
All are integrated with Maven 1.x in our case and tied into Hudson, which runs our builds on check-in as well as extra things nightly and weekly. Hudson trend graphs our JUnit tests, coverage, findbugs, as well as open tasks. There is also a Hudson plugin that reports and graphs our compile warnings. We also have several performance tests with their own graphs of performance and memory use over time using the Hudson plots plugin as well.