[
https://issues.apache.org/jira/browse/LUCENE-3973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14313404#comment-14313404
]
Robert Muir commented on LUCENE-3973:
-------------------------------------
Here's my patch for tooling for javac warnings. I don't think more tooling is
needed on the javac side, no fancy ant macros, no bikesheds, instead just code
fixing. Folks can either fix the warnings, or add \@SuppressWarnings and fix
them later. This way, any new warnings will fail the build if introduced.
If this is too much to handle at once, and we want to do it per-module, then
put a javac.args="-Xlint:all" before common-build.xml is imported, in each
module that fails.
{noformat}
Index: lucene/common-build.xml
===================================================================
--- lucene/common-build.xml (revision 1658537)
+++ lucene/common-build.xml (working copy)
@@ -164,7 +164,8 @@
<property name="javac.debug" value="on"/>
<property name="javac.source" value="1.8"/>
<property name="javac.target" value="1.8"/>
- <property name="javac.args" value="-Xlint -Xlint:-deprecation -Xlint:-serial
-Xlint:-options"/>
+ <!-- all warnings, except deprecation. -->
+ <property name="javac.args" value="-Werror -Xlint:auxiliaryclass -Xlint:cast
-Xlint:classfile -Xlint:-deprecation -Xlint:dep-ann -Xlint:divzero -Xlint:empty
-Xlint:fallthrough -Xlint:finally -Xlint:options -Xlint:overloads
-Xlint:overrides -Xlint:path -Xlint:processing -Xlint:rawtypes -Xlint:static
-Xlint:try -Xlint:unchecked -Xlint:varargs"/>
<property name="javadoc.link"
value="http://download.oracle.com/javase/8/docs/api/"/>
<property name="javadoc.link.junit"
value="http://junit.sourceforge.net/javadoc/"/>
<property name="javadoc.packagelist.dir"
location="${common.dir}/tools/javadoc"/>
{noformat}
> 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: LUCENE-3973.patch, LUCENE-3973.patch, LUCENE-3973.patch,
> LUCENE-3973.patch, LUCENE-3973.patch, LUCENE-3973.patch, LUCENE-3973.patch,
> LUCENE-3973.patch, core.html, 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.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
