So this is going to be optional and turned on locally ( having just been working on getting the logs to fit in travis ). Also: would running a build with this and reviewing pr code for warnings be a new step added to the contribution instructions?
On November 10, 2016 at 16:28:25, Justin Leet ([email protected]) wrote: Here's a gist with the output using that branch I gave. https://gist.github.com/justinleet/8d514727a0caeb5db2b4f76de0607214 On Thu, Nov 10, 2016 at 4:15 PM, Nick Allen <[email protected]> wrote: > Good discussion to have, Justin. Any chance you could past the Error Prone > output into a Gist or something similar? I'm really lazy sometimes, but > would love to see what it can do. :) > > I've always wanted to see a more enhanced Checkstyle configuration. I > think we have a minimal Checkstyle configuration that checks for license > headers (pre Apache Rat). As we mature, a more consistently styled code > base would be nice to have. I really don't care what style we choose. > > On Wed, Nov 9, 2016 at 11:59 AM, Justin Leet <[email protected]> > wrote: > > > Hi all, > > > > 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 > > > > > > Justin > > > > > > -- > Nick Allen <[email protected]> >
