[
https://issues.apache.org/jira/browse/METRON-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705751#comment-15705751
]
Justin Leet commented on METRON-593:
------------------------------------
It's built in to a given version of error-prone. The actual bugpatterns are
implemented at [Bug
Patterns|https://github.com/google/error-prone/tree/master/core/src/main/java/com/google/errorprone/bugpatterns]
in their repo. The webpage's docs are, as noted on the
http://errorprone.info/bugpatterns, are autogenerated from that source. For
example, MissingOverride.java results in
http://errorprone.info/bugpattern/MissingOverride, which would be how the
compilation knows what link to generate (I assume, but I haven't dug into their
source that much).
At that point, updating to latest ruleset is a matter of updating error-prone
(which should be updating the version in the pom, and fixing any new errors
that arise).
As a sidenote, as we fix warnings, we can start promoting those to errors (or
turn them off if we determine they're not something we're actually concerned
bout) if we want as described in http://errorprone.info/docs/flags.
> 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)
