[ 
https://issues.apache.org/jira/browse/LUCENE-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Jelinski updated LUCENE-3973:
------------------------------------
    Attachment: findbugs-lucene.patch

Attached proof-of-concept patch implements ant findbugs on Lucene (Solr not 
included); fails the build if any warnings are found.
It generates a report (HTML) file in build/findbugs/lucene.html.
Now. I can add findbugs to jenkins-nightly, so that we could link to findbugs 
results from [developer page|https://lucene.apache.org/core/developer.html], 
similar to what is done for 
[Clover|https://builds.apache.org/job/Lucene-Solr-Clover-master/lastSuccessfulBuild/clover-report/dashboard.html].
 This would become obsolete if SOLR-5869 is implemented, because Sonar does a 
Findbugs scan. But then, I don't see much going on under SOLR-5869.
I could also create a (XML) filter that would exclude all current bugs, and 
fold findbugs into precommit.
Thoughts?

> Incorporate PMD / FindBugs
> --------------------------
>
>                 Key: LUCENE-3973
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3973
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: general/build
>            Reporter: Chris Male
>              Labels: newdev
>         Attachments: core.html, findbugs-lucene.patch, LUCENE-3973.patch, 
> LUCENE-3973.patch, LUCENE-3973.patch, LUCENE-3973.patch, LUCENE-3973.patch, 
> LUCENE-3973.patch, LUCENE-3973.patch, LUCENE-3973.patch, solr-core.html
>
>
> This has been touched on a few times over the years.  Having static analysis 
> as part of our build seems like a big win.  For example, we could use PMD to 
> look at {{System.out.println}} statements like discussed in LUCENE-3877 and 
> we could possibly incorporate the nocommit / @author checks as well.
> There are a few things to work out as part of this:
> - Should we use both PMD and FindBugs or just one of them? They look at code 
> from different perspectives (bytecode vs source code) and target different 
> issues.  At the moment I'm in favour of trying both but that might be too 
> heavy handed for our needs.
> - What checks should we use? There's no point having the analysis if it's 
> going to raise too many false-positives or problems we don't deem 
> problematic.  
> - How should the analysis be integrated in our build? Need to work out when 
> the analysis should run, how it should be incorporated in Ant and/or Maven, 
> what impact errors should have.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to