Justin Leet created METRON-593:
----------------------------------
Summary: Enable an automated static analysis tool in the build
Key: METRON-593
URL: https://issues.apache.org/jira/browse/METRON-593
Project: Metron
Issue Type: Improvement
Reporter: Justin Leet
Assignee: Justin Leet
>From on a discussion thread I kicked off on the dev list. Some newer notes
>follow
h4. Original Email
I wanted to kick off a discussion about integrating a static analysis tool into
our builds.
The main discussion points I wanted to start up (and feel encouraged to add
more):
1) Most importantly, do we get enough value by adding a tool?
2) What are we looking for out of a tool (Extensibility to add our own checks,
plugged into build cycle directly, ease of use, customizability, etc.)?
3) Are there any particular tools people have experience with?
4) Assuming we want to roll something out, what's the best path? My current
assumption is that it's probably easiest to handle things on a pom by pom
basis, rather than trying to do everything at once, but there may be more
nuance people want to add.
The main one I've used FindBugs, but there's a been discussion lately about
issues with their community which led me to take a (very) brief glance at into
Google's errorprone. It seems like it's an alternative worth considering from
what I've seen.
Some links to errorprone info:
http://errorprone.info/
https://github.com/google/error-prone
http://errorprone.info/bugpatterns
I played around with it for about 2 minutes, and was able to get it up and
running and happily complaining about metron-common during it's build cycle.
Haven't dug too much into the errors/warnings to get a sense of signal to noise
ratio. If anybody is interested in playing around with that setup for
metron-common, I have a branch at:
https://github.com/justinleet/incubator-metron/tree/errorprone
Just go to metron-platform/metron-common and run:
mvn compile
Gist with the error prone output.
https://gist.github.com/justinleet/8d514727a0caeb5db2b4f76de0607214
h4. New notes
After playing around with error prone a bit more (I was able to get it running
on most of our modules and fix build breaking errors pretty quickly), it
provides significantly less check coverage than findbugs, but has the benefit
of being directly tied into the compile (meaning people can get feedback and
errors pretty quickly). Related to this, the errors that error prone gave out
were actual issues (although relatively minor in our codebase, e.g. catching
issues with format() calls).
It seems the benefits of error prone fall primarily on it coming earlier in the
lifecycle to give feedback quicker and being actively maintained and improved.
The main benefit of findbugs is being a broader set of checks, but at the
expense of being later in the build cycle (because it operates on bytecode),
and the community being in an odd place right now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
