Skip to content
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

Bump and simplify a dep and a plugin. #6450

Closed
wants to merge 1 commit into from
Closed

Conversation

copybara-service[bot]
Copy link
Contributor

Bump and simplify a dep and a plugin.

The main motivation to this CL is to pick up a fix to Animal Sniffer: The old version of Animal Sniffer ignores suppression annotations when it looks at fields, and that was causing me problems as I tried to use a field of type FileAttribute.

While I was at it, I ran the usual command for updating deps (but not plugins), as documented in cl/503506407.

And then, I inlined a couple properties into the dependencyManagement entries that used them. We'd introduced the properties because we used to use multiple artifacts that were released together. However, we don't use multiple artifacts with those properties anymore:

  • We stopped using the Animal Sniffer annotations way back in cl/273964192, leaving only the Animal Sniffer plugin.
  • We stopped using the Checker Framework's compat-qual annotations back in cl/399471446 - cl/399480336, leaving only the main qual annotations.
    • But we had temporarily introduced a usage of the sources artifact for qual in cl/364918297. We removed the usage of it in cl/399190627 but left behind the dependencyManagement entry. So this CL removes that, too.

(It's possible that we'd want to move away from using properties for versions in general: While Guava doesn't use Dependabot for pom.xml updates (only for GitHub Actions updates, which are easily for our tools to import), we can still update all deps by running a command. So we're not stuck hand-editing multiple locations, and thus all the property provides a layer of indirection. However, until we have a way to automatically update plugins, there is some sense in using properties for plugin versions. Or at least there's sense in it for any properties that we still need to use in multiple places. But we might not need to use many (any?) in multiple places anymore, since we finally solved the mystery of why our pluginManagement section wasn't being respected back in cl/492304151....)

RELNOTES=n/a

The main motivation to this CL is to pick up [a fix to Animal Sniffer](mojohaus/animal-sniffer#212): The old version of Animal Sniffer ignores suppression annotations when it looks at fields, and that was causing me problems as I tried to use a field of type `FileAttribute`.

While I was at it, I ran the usual command for updating deps (but not plugins), as documented in cl/503506407.

And then, I inlined a couple properties into the `dependencyManagement` entries that used them. We'd introduced the properties because we used to use multiple artifacts that were released together. However, we don't use multiple artifacts with those properties anymore:
- We stopped using the Animal Sniffer _annotations_ way back in cl/273964192, leaving only the Animal Sniffer plugin.
- We stopped using the Checker Framework's `compat-qual` annotations back in cl/399471446 - cl/399480336, leaving only the main `qual` annotations.
  - But we had temporarily introduced a usage of the `sources` artifact for `qual` in cl/364918297. We removed the usage of it in cl/399190627 but left behind the `dependencyManagement` entry. So this CL removes that, too.

(It's possible that we'd want to move away from using properties for versions in general: While Guava doesn't use Dependabot for `pom.xml` updates (only for GitHub Actions updates, which are easily for our tools to import), we can still update all deps by running a command. So we're not stuck hand-editing multiple locations, and thus all the property provides a layer of indirection. However, until we have a way to automatically update _plugins_, there is some sense in using properties for _plugin_ versions. Or at least there's sense in it for any properties that we still need to use in multiple places. But we might not need to use many (any?) in multiple places anymore, since we finally solved the mystery of why our `pluginManagement` section wasn't being respected back in cl/492304151....)

RELNOTES=n/a
PiperOrigin-RevId: 526467147
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant