Forbiddenapis: Split the guava16-only signatures file from main signatures file

[uschindler]

Improves workaround introduced in #12158.

Description

In #12158 the fix to workaround an issue with forbiddenapis parsing a missing signature in later Guava versions (actualy it is two of them) was to enable a now-deprecated maven plugin setting: <failOnUnresolvableSignatures>false</failOnUnresolvableSignatures>

This flag is very risky as it ignores signatures with typos in it. This was made as a workaround for subprojects where some dependencies are missing, but birngs the risk of not cathcing bugs because of typos.

In forbiddenapis 3.1 / 3.2 a new setting was added ignoreSignaturesOfMissingClasses=true, as this still prevents typos in signatures and just ignores those where the class is not existent. It then also prints no warnings anymore!

The problem with that is that in case of Guava, which uses a newer version of Guava in telemetry-emitter, a deprecated method was removed, so it triggers "class found, but method missing".

The "correct" fix for those issues is to use separate signatures files per dependency and only load them in sub-projects when the dependency is used. For guava there should be 2 separate files. Unfortunately Maven is a bit limited, as you cannot make the signatures file names dynamic based on dependency versions. Lucene has gone this approach (we have a set of files per dependency) and based on the Maven coordinates our Gradle build script enables them.

In this PR I used a hack, which requires a bit copypaste, because you can't modify configurations of plugin, just replace (default) or add new list items, but not remove them:

• a new signatures file was added: guava16-forbidden-apis.txt
• it is enabled by default in parent POM
• for telemetry-emitters the signatures files property is duplicated, with the above file removed.

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[uschindler]

I also updated plugin version to 3.2.

[uschindler]

The build failure by Travis is not related to this change, a test is failing? Can you retrigger?

[jihoonson]

@uschindler thank you for the PR! Our CI is very flaky recently. Sorry about that. I restarted the failed one.

[jihoonson]

LGTM. @uschindler I will merge if the CI still fails as it's obvious that the failure is unrelated to your change.

[uschindler]

Thanks. The other ignoreSignaturesOfMissingClasses is still enabled, as otherwise ICU checks fail on some subprojects not including ICU.

Maybe in future the same should be done: Have a separate file only with ICU signatures and just add them on subprojects where ICU is actually used. One way to do this is (according to Maven doc, untested):

<signaturesFiles combine.children="append">
  <signaturesFile>path/to/icu-signatures.txt</directory>
</signaturesFiles>

This would add the signaturesFile to the ones inherited from parent. This is useful for lists. Unfortunately there's no way to remove some from the parent list - this is why I needed to replcate the whole config in the current PR.

[jihoonson]

Thank you for the suggestion. It sounds reasonable to me.

The Travis CI failed again with the same error as reported in #12171. I'm going to ignore it and merge this PR. Thanks @uschindler!