[
https://issues.apache.org/jira/browse/METRON-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705925#comment-15705925
]
ASF GitHub Bot commented on METRON-593:
---------------------------------------
GitHub user justinleet opened a pull request:
https://github.com/apache/incubator-metron/pull/376
METRON-593: Enable an automated static analysis tool in the build
Setup everything to use [Error Prone](http://errorprone.info/) with errors
fixed and warnings on. This increases build output, but it still seems fairly
manageable.
We had a lot of the poms redefining the maven-compiler-plugin entirely, or
just adding ```<compilerArgument>-Xlint:unchecked</compilerArgument>```, so I
made them all just inherit from the root pom with ```-Xlint:unchecked``` on.
It seems reasonable to leave it on everywhere, and simplifies the POMs, but if
anyone has a strong objection, it's easy to change it to whatever we want.
Assuming we're good with this approach to our static analysis, we'd create
a follow on ticket (or tickets?) to address them. After addressing them, we
probably should swing back around and upgrade some or all of our warnings to
errors, so we don't have to deal with them cropping up again.
Tests were run successfully and quick-dev was spun up to with some data
pushed through.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/justinleet/incubator-metron errorprone
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-metron/pull/376.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #376
----
commit 0da475301dc4dba9a3f316c7e0b2b07d935e7e97
Author: justinjleet <[email protected]>
Date: 2016-11-09T16:31:04Z
errorprone on common
commit 426844d5610a4e9a04fac86d794cab9ece27d696
Author: justinjleet <[email protected]>
Date: 2016-11-29T15:29:38Z
Extending to all modules, errors fixed
commit 3da4ca496cad0986163c1406cdb6c522c2d9439a
Author: justinjleet <[email protected]>
Date: 2016-11-29T17:06:08Z
Inheriting compiler from root pom, rather than redefining everywhere
----
> 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
>
> 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)
