[
https://issues.apache.org/jira/browse/METRON-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Leet updated METRON-593:
-------------------------------
Fix Version/s: Next + 1
> 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
> Affects Versions: 0.3.0
> Reporter: Justin Leet
> Assignee: Justin Leet
> Fix For: Next + 1
>
>
> 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)
