[jira] [Commented] (METRON-593) Enable an automated static analysis tool in the build

["Justin Leet (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/METRON-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705606#comment-15705606 ] 

Justin Leet commented on METRON-593:
------------------------------------

For adding error-prone to all the projects, with all error level issues fixed.  Warnings have not been fixed (and result in appropriate additional build output).

My personal branch is updated with these changes, and I'm putting it out so people can look at it.  Tests have been run, but quick-dev has not been run yet.

Output of the build:
https://gist.github.com/justinleet/1082bc86dd53abad1f34aa7bf0519a67

> 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)