techblog 

I have been introducing Coverity Prevent for Java into our continuous integration stream,  so I decided to post some comments about it.

Installing the software is not difficult at all, just uncompress the files and get a license. Starting to analyze code is also quite easy following the Quick Start Guide, once you get it working you can progressively tune the analysis for your needs . The program supports a great variety of platforms and operative systems so it is very likely that it will work in any kind of machine you happen to have your code and binaries on. It also does a great job detecting failures, quite clever stuff.

However when it comes to integrate Coverity Prevent with your build system it is not as straight forward. You code in Java, don’t you? so it is very likely that you use ant to build the system, but there is no support for ant to run Coverity Prevent. The program runs as a number of native applications or shell scripts called with several parameters, therefore I had to write a few shell scripts to run the different programs with the correct parameters and then use the exec ant task to call those scripts. I would have been quite happy if I could just drop some libs into ant directory and run an hypothetical prevent_analyze task from the ant build script.

Coverity Prevent stores found defects into a proprietary database and you can manage and query this database via web using an embedded web server or via command line. The embedded web server is another annoying thing, as we are already running an application server in the machine for the continuous integration testing, I think it would be good that the web interface was also provided as a java web application deployable into the web application server which you are likely to be using and managing.

Apart from that, the access via web looks nice,  you can see the defect description and explanation. It allows you to classify the error as intentional or a real bug. You can also assign a severity to a given defect, and specify an action to mark the defects to be resolved, expected to be fixed or ignored. When finding defects, it allows you to visualize defects by product, by component into a given product, sort them by any field, etc.

When accessing via the command line you can perform all the same operations and even more, allowing a great degree of automation and produce reports on the information stored in the defect database. This functionality allowed us to extract some statistics on the number of defects and defect listings to be presented in our build results main page. Using the web access was less useful as user need to log into the web application to be able to see results and we wanted some output to embed into the reporting system and have the current state at a glance.

The need to log in and the fact that the graphs produced in the web view are done with interactive flash prevented us to have a nice main page showing graphs along with the statistics. It would have been nice to have the command line query to produce PNG images with those graphs instead of interactive flash applications. It could be done with the query command line and some plotting package such as ploticus or gnuplot but it would require too much time to be invested on.

In conclusion, I have to say that it is a good analysis tool which detects many pitfalls in the code and it really helps, but it is yet another tool to add to the defect management pool of tools as we are already using Jira for that purpose, asking a plugin to integrate them would probably be too much ;)