Thanks Tim.

I think we will be able to remove findbugs after some run/check using 
ErrorProne and see the gaps.

Regards
JB

Le 18 mai 2018 à 07:49, à 07:49, Tim Robertson <timrobertson...@gmail.com> a 
écrit:
>Thank you all.
>
>I think this is clear.  Removing findbugs can happen at a future point.
>
>@Scott - I've been working through the java IO error prone issues (some
>already merged, some with open PRs now) so will take those IO Jiras. I
>will
>enable failOnWarning, address dependency issues for findbugs and tackle
>the
>error prone warnings.
>
>
>On Fri, May 18, 2018 at 1:07 AM, Scott Wegner <sweg...@google.com>
>wrote:
>
>> +0.02173913
>>
>> I'm happy to replace FindBugs with ErrorProne, but we need to first
>> upgrade ErrorProne analyzer warnings to errors. Currently the
>codebase is
>> full of warning spam, and there's no enforcement preventing future
>> violations from being added.
>>
>> I've done the work for enforcing ErrorProne analysis on java-sdk-core
>[1],
>> and I've sharded out the rest of the Java components in JIRA issues
>[2] (45
>> total).  Fixing the issues is relatively straightforward, and I've
>tried to
>> provide enough guidance to make them as starter tasks (example: [3]).
>Teng
>> Peng has already started on Spark [4] (thanks!)
>>
>> [1] https://github.com/apache/beam/pull/5319
>> [2] https://issues.apache.org/jira/issues/?jql=project%20%
>>
>3D%20BEAM%20AND%20status%20%3D%20Open%20AND%20labels%20%3D%20errorprone
>> [3] https://issues.apache.org/jira/browse/BEAM-4347
>> [4] https://issues.apache.org/jira/browse/BEAM-4318
>>
>> On Thu, May 17, 2018 at 2:00 PM Ismaël Mejía <ieme...@gmail.com>
>wrote:
>>
>>> +0.7 also. Findbugs support for more recent versions of Java is
>lacking
>>> and
>>> the maintenance seems frozen in time.
>>>
>>> As a possible plan b can we identify the missing important
>validations to
>>> identify how much we lose and if it is considerable, maybe we can
>create a
>>> minimal configuration for those, and eventually migrate from
>findbugs to
>>> spotbugs (https://github.com/spotbugs/spotbugs/) that seems at least
>to
>>> be
>>> maintained and the most active findbugs fork.
>>>
>>>
>>> On Thu, May 17, 2018 at 9:31 PM Kenneth Knowles <k...@google.com>
>wrote:
>>>
>>> > +0.7 I think we should work to remove findbugs. Errorprone covers
>most
>>> of
>>> the same stuff but better and faster.
>>>
>>> > The one thing I'm not sure about is nullness analysis. Findbugs
>has some
>>> serious limitations there but it really improves code quality and
>prevents
>>> blunders. I'm not sure errorprone covers that. I know the Checker
>analyzer
>>> has a full solution that makes NPE impossible as in most modern
>languages.
>>> Maybe that is easy to plug in. The core Java SDK is a good candidate
>for
>>> the first place to do it since it is affects everything else.
>>>
>>> > On Thu, May 17, 2018 at 12:02 PM Tim Robertson <
>>> timrobertson...@gmail.com>
>>> wrote:
>>>
>>> >> Hi all,
>>> >> [bringing a side thread discussion from slack to here]
>>>
>>> >> We're tackling error-prone warnings now and we aim to fail the
>build on
>>> warnings raised [1].
>>>
>>> >> Enabling failOnWarning also fails the build on findbugs warnings.
>>> Currently I see places where these  arise from missing a dependency
>on
>>> findbugs_annotations and I asked on slack the best way to introduce
>this
>>> globally in gradle.
>>>
>>> >> In that discussion the idea was floated to consider removing
>findbugs
>>> completely given it is older, has licensing considerations and is
>not
>>> released regularly.
>>>
>>> >> What do people think about this idea please?
>>>
>>> >> Thanks,
>>> >> Tim
>>> >> [1]
>>> https://lists.apache.org/thread.html/95aae2785c3cd728c2d3378cbdff2a
>>> 7ba19caffcd4faa2049d2e2f46@%3Cdev.beam.apache.org%3E
>>>
>>

Reply via email to