How to suppress gradle deprecation warnings

I would like to update to gradle 4.2, but I start getting a deprecation warning on every clean build. The warning is because of a newly deprecated API in one of the plugins I’m using. Is there a way to suppress this warning in my build file?

A newer version of the plugin isn’t yet available. Since the warning doesn’t specify that it’s coming from one of the plugins, it makes it seem like it’s a failure in our code. I know people will start filing tickets about the warning, and since it’s not a problem until we choose to upgrade to 5.0 I’d like to just hide it.

1 Like

Is there a way to suppress this warning in my build file?

At the moment you cannot suppress deprecation warnings. To be honest I feel that if we’d allow user to do that then everyone would simply turn them off and forget about them until the next release.

A newer version of the plugin isn’t yet available. Since the warning doesn’t specify that it’s coming from one of the plugins, it makes it seem like it’s a failure in our code.

I’d agree that the message can be somewhat bothersome especially if you have no control about it. The warning does specify the source but only if you run with -s.

I know people will start filing tickets about the warning…

I suggest making your voice hear. The higher an issue is voted the higher the possibility that we actually do something about it. Feel free to create a new issue if you think it doesn’t exist yet. Community contributions are highly welcome!

1 Like

At the moment you cannot suppress deprecation warnings. To be honest I feel that if we’d allow user to do that then everyone would simply turn them off and forget about them until the next release.

Yeah, we all know that suppressing warnings can be a bad idea. But please let us developers make that choice.

Kotlin’s @Suppress and Java’s @SuppressWarnings were introduced for good reason. Getting used to seeing warnings is bad. Even worse when they cannot be fixed.

Unfixable warnings hide new real warnings and makes it impossible to have a “No warnings in the build” policy which is much, much more important for large-project health.

So it is one thing if the @Suppress* annotations don’t work for some technical and/or historical reason. But I urge reconsideration if they aren’t supported based on a principle.

This github comment suggests:

@Suppress("DEPRECATION")
mainClassName ="<your main class here>"

But gradle 6.7 (that deprecated mainClassName) still reports:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.7/userguide/command_line_interface.html#sec:command_line_warnings
3 Likes

I agree that a way to suppress specific build warnings would be great and actually allow us to better stay on top of warnings.

Currently, we ignore Gradle warnings and spot check for them.

I would like to turn on --warning-mode=fail and just fix our dozens of build warnings but we inherit a few from our dependencies. Without a way to suppress specific warnings, we can’t do strict builds.

However, if we had a feature like a lint baseline, we could set --warning-mode=fail to fail our build at each PR to immediately address any new warnings. If any new warnings appeared from our dependencies, we would file an upstream bug to fix the actual problem and update our baseline to unblock us in the meantime. We do this exact flow for lint and it works great.

In summary, a baseline warning suppression feature would let us pay more attention to our build warnings (solving problems as the occur) and help contribute to our dependencies for everyone’s benefit.

3 Likes

What did the trick for me, suppressing all warnings with usage of -q flag (I am aware that in this case all the warnings will be suppressed not only deprecation ones). Command-Line Interface (gradle.org).
Now first you check the warnings without the flag, create tasks for resolving them then disable warnings in logs. For debugging purposes you can use standard logger or -w flag again.