[
https://issues.apache.org/jira/browse/LUCENE-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13941476#comment-13941476
]
Uwe Schindler edited comment on LUCENE-5130 at 3/20/14 7:16 AM:
----------------------------------------------------------------
Shawn: this was referring to the actual config of the warnings:
{code:xml}
<property name="javac.args" value="-Xlint -Xlint:-deprecation -Xlint:-serial
-Xlint:-options"/>
{code}
This setting has the effect that *all* warnings are enabled ({{-Xlint}}) minus
the ones listed ({{-Xlint:-deprecation -Xlint:-serial -Xlint:-options}}). For
pure warnings, this is no problem at all. But if we *fail* on warnings, this
combination of flags is a bad idea: E.g.Java 8 or Java 9 or another compiler
like J9's has another set of "default" warnings (the ones enabled by
{{-Xlint}}). If somebody uses this newer version, the build will fail for no
reason.
Because of this: If we fail builds on warnings, we should give an explicit list
of warnings to report, like:
{code:xml}
<property name="javac.args" value="-Xlint:+unchecked -Xlint:+rawtypes
-Xlint:+fallthrough ..."/>
{code}
In that case, we dont compile against a unknown set of warnings (which may fail
our build on newer Oracle JDKs or different JDK vendors), but against a set of
warnings we agreed on.
In short: I am against to fail the build on warnings, if the set of warnings is
not defined explicit.
was (Author: thetaphi):
Shawn: this was referring to the actual config of the warnings:
{code:xml}
<property name="javac.args" value="-Xlint -Xlint:-deprecation -Xlint:-serial
-Xlint:-options"/>
{code}
This setting has the effect that *all* warnings are enabled ({{-Xlint}}) minus
the ones listed ({{ -Xlint:-deprecation -Xlint:-serial -Xlint:-options}}). For
pure warnings, this is no problem at all. But if we *fail* on warnings, this
combination of flags is a bad idea: E.g.Java 8 or Java 9 or another compiler
like J9's has another set of "default" warnings (the ones enabled by
{{-Xlint}}). If somebody uses this newer version, the build will fail for no
reason.
Because of this: If we fail builds on warnings, we should give an explicit list
of warnings to report, like:
{code:xml}
<property name="javac.args" value="-Xlint:+unchecked -Xlint:+rawtypes
-Xlint:+fallthrough ..."/>
{code}
In that case, we dont compile against a unknown set of warnings (which may fail
our build on newer Oracle JDKs or different JDK vendors), but against a set of
warnings we agreed on.
In short: I am against to fail the build on warnings, if the set of warnings is
not defined explicit.
> fail the build on compilation warnings
> --------------------------------------
>
> Key: LUCENE-5130
> URL: https://issues.apache.org/jira/browse/LUCENE-5130
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Fix For: 4.8
>
> Attachments: LUCENE-5130.patch, LUCENE-5130.patch
>
>
> Many modules compile w/o warnings ... we should lock this in and fail the
> build if warnings are ever added, and try to fix the warnings in existing
> modules.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
