Add option to suppress warning about unresolved signature

I'm using the gradle plugin, version 2.0 . Please consider suppressing the warning about unresolved signature i.e. this signature:
Class 'com.google.inject.Inject' not found on classpath while parsing signature: com.google.inject.Inject [signature ignored]

The use case is as follows:

• I have a multi-project gradle build, where some subprojects often use different libraries.
• I would like to have a single top-level forbidden signatures file.
• When a project starts using a library and also uses a forbidden method, i would like there to be an error. (e.g. in this case, I want to mandate that Guice users use the JSR-330 annotations instead of the guice annotations, however not all subprojects are using guice yet).

The failOnUnresolvableSignatures = false option makes the build still pass, but currently my build logs are polluted with messages about signatures for libraries from other projects.

That being said, I just started using the plugin, and I'm open to ideas about how to better achieve my goals. Thank you for this useful plugin.

[uschindler]

Thanks for using & testing the (new) gradle plugin!

I know about this issue, one possibility would be to just print a single-line warning and only print the other ones on verbose logging.

Another possibility would be to make the signatures dependent on sub module. You could define and preconfigure the task in the parent module, but make the signatures part using a configuration (see https://docs.gradle.org/current/dsl/org.gradle.api.artifacts.ConfigurationContainer.html). As the signaturesFiles property is a FileCollection, you can define a configuration (like the well known "compile" config for setting all compile dependencies). In the parent project leave the config empty. In the forbiddenapis task use signaturesFiles: configurations.XXX in parent project.

In the sub module you could then redefine the configuration and adding files to it, or altenatively provide multiple configurations and choose the one you like.

These are just suggestions!

I will work on the idea to conflate the warning to a signle line warning with more info on verbose.

[uschindler]

In the sub module you could then redefine the configuration and adding files to it, or altenatively provide multiple configurations and choose the one you like.

With some Groovy Magic maybe you can make a condition in the configuration like...: if (configurations.compile.contains("guice")) add guice signatures file

Just as idea, not tested it's just pseudo code. But as Gradle is plain Groovy, you can use any language construct to build configurations or tasks. If I find some easy way, I could add that as howto to the wiki.

In any case this is much cleaner than supressing warnings (and less error prone: If you have a typo in a signature, you would not recognize that!)

Thank you for your reply.

I think the single warning will go a long way. In the meantime, I'll look into the ideas you suggested:

• setting everything but the signatures in the parent project
• or, inspecting the dependencies and deciding whether to add a particular signature.

[dweiss]

I'd also love to see some kind of "quiet" mode for unresolved signatures. This way you could reuse a single definition forbidden APIs within a multi-module build without seeing tons of warnings. Yes, I know the risks, but I'd rather live with these than modify the plugin's config in every single sub-project.

          } else if (line.equals(IGNORE_UNRESOLVABLE_LINE)) {
            reporter = isBundled ? UnresolvableReporting.SILENT : UnresolvableReporting.WARNING;

This would make me happy, but it's only applied to bundled signatures. Do you think it could be just switched to reporter = SILENT for all signature files?

[dweiss]

Hi Uwe. I know it's been a long time, but do you think it'd be a good time to reconsider allowing ignoreUnresolvable to work in non-bundled specs (see my comment above; it's essentially a one-liner modification).

[uschindler]

Another idea would be to make the failOnUnresolvableSigantures and 3state flag (new name), to disable the warning. Or maybe add a hideWarnings switch. So one can use warnings enabled during setup of build system and disable them when sigantures files were finalized.

I am still a bit nervous about allowing to always hide the signatures lookup errors, because by a small typo your signatures get useless (and you have no way to test it).

[uschindler]

Would it be maybe ok, to allow to reduce the warning to a single line?: "WARNING: there are forbidden signatures that do not resolve. Use mvn verify -Dforbiddenapis.hideWarnings=false to show them."

[dweiss]

I understand the typo issue (and abuse of the potential silencing annotation). The truth is, however, that it's much, much easier to write a single set of rules in a multi-module project and import them once than configure the plugin in each and every module. Call it the "lazy" way. ;)

I wonder if ignoreUnresolvable could take a package or class name as an argument: if this is non-resolvable then the rules for the entire block would be ignored. Something like this.

@defaultMessage Use Java7/8 semantics
@ignoreIfMissing com.google.common.collect.Lists
com.google.common.collect.Lists#newArrayList()
com.google.common.collect.Lists#newArrayList(java.lang.Object[]) 

This does increase the complexity of the definition files, unfortunately.

[uschindler]

@ignoreIfMissing com.google.common.collect.Lists looks like a cool idea. Because it would only be silent if the class is missing. In the parts of your project, where Google Guava is imported, it will fail if signature is wrong, otherwise it will be silent. I will think about that. I like that much more than silencing.

The @ignoreUnresolvable line was only meant to be used in the jdk.deprecated files bundled with forbidden, because those signatures are autogenerated and will therefore always resolve (unless removed in later JDK versions, which happened in Java 9), typos impossible.

[uschindler]

I am taking care of this now. My proposal (after lots of thinking): There are 2 types of problems in signatures: Missing classes and missing methods/fields. If the class is missing, it's enough to collect those non-existent classes and just long one warning message at the end. In contrast, if the class is there, but the method/field is missing, it's more serious. So we log the warning for each broken signature. If failures are enabled, nothing changes - it will bail out with error message.

[dweiss]

Will this include that "ignoreIfMissing com.google.common.collect.Lists" to allow (optional) silence on missing entire classes? :)