You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Florent Biville <fl...@gmail.com> on 2022/09/14 14:51:56 UTC

Plans to deprecate or change the default value of maven compiler plugin's showWarnings

Hi everyone,

A colleague of mine recently stumbled upon this
<https://stackoverflow.com/questions/9192613/how-do-i-get-a-java-maven-build-to-fail-for-compiler-warnings/33823355#33823355>
.

Quoting the above Stackoverflow answer:

> <showWarnings>true</showWarnings> is required. For reasons unknown, Maven
> by default actively suppresses warnings with the -nowarn flag, so the
> -Xlint and -Werror flags would be ignored.
>

I assume that warnings are suppressed by default because the default value
of showWarnings is false?

If that's the case, I wonder why we need such an accessible option is
necessary since the other related warning options would have to go through
compilerArgs.

I also realize my question is relevant to other settings.

Is there a plan to deprecate this kind of settings and remove them at a
next major version?
In the specific case of showWarnings, if deprecation and removal are not an
option, could changing the default value to true be considered for the next
major version (or maybe some other value that means the setting is not
initialized and should not interfere with warnings)?

Thanks for your help!
Florent

Re: Plans to deprecate or change the default value of maven compiler plugin's showWarnings

Posted by Florent Biville <fl...@gmail.com>.
Thanks for the reply!

Can I go ahead and open an issue and/or a PR?

> What other settings do you have in mind?

Maybe the same logic could apply to showDeprecation but I have not thought
about it too much and the situation may be a bit different there.

On Thu, Sep 22, 2022 at 10:31 AM Olivier Lamy <ol...@apache.org> wrote:

> On Thu, 15 Sept 2022 at 00:52, Florent Biville <fl...@gmail.com>
> wrote:
>
> > Hi everyone,
> >
> > A colleague of mine recently stumbled upon this
> > <
> >
> https://stackoverflow.com/questions/9192613/how-do-i-get-a-java-maven-build-to-fail-for-compiler-warnings/33823355#33823355
> > >
> > .
> >
> > Quoting the above Stackoverflow answer:
> >
> > > <showWarnings>true</showWarnings> is required. For reasons unknown,
> Maven
> > > by default actively suppresses warnings with the -nowarn flag, so the
> > > -Xlint and -Werror flags would be ignored.
> > >
> >
> > I assume that warnings are suppressed by default because the default
> value
> > of showWarnings is false?
> >
>
> correct.
> the source for this is here
>
> https://github.com/codehaus-plexus/plexus-compiler/blob/79d1a5fdd237a736ad58fd346a975d5d37046a15/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java#L353
>
> I agree this could be improved. Especially everything around the isShowLint
> method
>
>
> >
> > If that's the case, I wonder why we need such an accessible option is
> > necessary since the other related warning options would have to go
> through
> > compilerArgs.
> >
>
> Historically (if I remember correctly) only the option '-nowarn' was
> available then came new compiler options
> well this could be done differently by fixing the use of isShowLint.
> the option is to suppress quickly every "noise" (e.g warnings)
>
>
> > I also realize my question is relevant to other settings.
> >
> > Is there a plan to deprecate this kind of settings and remove them at a
> > next major version?
> >
>
> What other settings do you have in mind?
>
>
> > In the specific case of showWarnings, if deprecation and removal are not
> an
> > option, could changing the default value to true be considered for the
> next
> > major version (or maybe some other value that means the setting is not
> > initialized and should not interfere with warnings)?
> >
>
> sounds good to me to change to true.
> changing from boolean to something might break some compatibility
> especially because other compilers.
>
>
> >
> > Thanks for your help!
> > Florent
> >
>

Re: Plans to deprecate or change the default value of maven compiler plugin's showWarnings

Posted by Olivier Lamy <ol...@apache.org>.
On Thu, 15 Sept 2022 at 00:52, Florent Biville <fl...@gmail.com>
wrote:

> Hi everyone,
>
> A colleague of mine recently stumbled upon this
> <
> https://stackoverflow.com/questions/9192613/how-do-i-get-a-java-maven-build-to-fail-for-compiler-warnings/33823355#33823355
> >
> .
>
> Quoting the above Stackoverflow answer:
>
> > <showWarnings>true</showWarnings> is required. For reasons unknown, Maven
> > by default actively suppresses warnings with the -nowarn flag, so the
> > -Xlint and -Werror flags would be ignored.
> >
>
> I assume that warnings are suppressed by default because the default value
> of showWarnings is false?
>

correct.
the source for this is here
https://github.com/codehaus-plexus/plexus-compiler/blob/79d1a5fdd237a736ad58fd346a975d5d37046a15/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java#L353

I agree this could be improved. Especially everything around the isShowLint
method


>
> If that's the case, I wonder why we need such an accessible option is
> necessary since the other related warning options would have to go through
> compilerArgs.
>

Historically (if I remember correctly) only the option '-nowarn' was
available then came new compiler options
well this could be done differently by fixing the use of isShowLint.
the option is to suppress quickly every "noise" (e.g warnings)


> I also realize my question is relevant to other settings.
>
> Is there a plan to deprecate this kind of settings and remove them at a
> next major version?
>

What other settings do you have in mind?


> In the specific case of showWarnings, if deprecation and removal are not an
> option, could changing the default value to true be considered for the next
> major version (or maybe some other value that means the setting is not
> initialized and should not interfere with warnings)?
>

sounds good to me to change to true.
changing from boolean to something might break some compatibility
especially because other compilers.


>
> Thanks for your help!
> Florent
>