[
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]