-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to ignore failures for some signature files only #219
Comments
I think it should result in hard errors, always. If you know the use is justified, you'll have to add SuppressForbidden to the piece of code that uses those APIs. This is an explicit step (and you can grep your code for those annotations). Realistically, nobody looks at the log scroll... |
That is a matter of policy. The
That is one option but not the only one. Note that I am not talking about “forbidden APIs that can be used in exceptional cases”, which is a perfect use case for annotations, but about APIs that are not recommended (but allowed), have known pitfalls, etc, where a warning is ok but failing the build would be too much.
Then In any case what I am proposing here is a way to add flexibility to an existing option, in a backwards compatible way. If someone does not want to use it, they don’t need to. |
Maybe - I didn't add it, Uwe did. I just expressed my opinion. :) |
It would be nice if forbidden-apis can be configured to ignore failures for some signature files and not for others.
This would make it possible to have a set of signature files for APIs that should never be used (i.e. broken, unsafe, etc), and using them would result in an error and fail the build, and a different set of signature files for APIs that are allowed but should be used with care / double checked (for example, APIs that are partially broken and should only be used under certain circumstances). The latter should result in warnings but not in hard errors.
Currently it does not seem possible to do that, at least in the Gradle DSL, which only allows a boolean
ignoreFailures
setting.Perhaps
ignoreFailures
could itself receive a list of signature files where failures should be ignored, and still allowtrue
andfalse
for backwards compatibility.The text was updated successfully, but these errors were encountered: