> > So this is going to be optional and turned on locally ( having just been > working > on getting the logs to fit in travis ).
I don't think the amount of build output would increase. For whatever tool we might add, we would just add it a project at-a-time and fix any issues/errors that arise in the same PR. Also: would running a build with this and reviewing pr code for warnings be > a new step added to the contribution instructions? Any static analysis tool would have to have a simple pass/fail criteria and be integrated with Maven. The CI build would either fail or succeed. There would be no additional manual step. On Fri, Nov 11, 2016 at 8:39 AM, Otto Fowler <[email protected]> wrote: > 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]> > > > -- Nick Allen <[email protected]>
