Use the ToolProvider SPI to run google-java-format #1795
Conversation
This makes the compile-time dependency on google-java-format optional.
|
|
|
thanks! Is there a strong reason to prefer the SPI or is it just a nicer practice? I can polish to pass the CI and switch to a runtime dependency to merge this. I'm not sure why it recompiled in each job instead of using the build cache, so sorry for that warning spam. |
This makes the compile-time dependency on google-java-format optional.
Thanks for the lightning fast review! The motivation for this was an internal bazel build for google-java-format. The formatter's tests depend on caffeine, which depends on google-java-format, so I was having to rebuild caffeine when testing some formatter changes. So not a common use-case, but I also didn't see downsides to using the SPI here. Thanks again! |
haha, well I know that fun. Caffeine's build depends on errorprone which depends on caffeine, and Gradle rewrites that to a project dependency so it relies on the pre-built classes. I have to trick it to include the jar. |
oh can you explain this? The published metadata, pom and module, don’t include that as a dependency. It should only be a build phase in this repository and not in a user’s, so it sounds like the thirdparty java_import rule might be excessive? |
The key part here was that this is an internal bazel build, which is building everything from source and not relying on the published artifacts. So it's probably really not a common use-case, but it's helpful being able to drop the build-time dep for that. |
|
great, I figured something like that and likely for reproducible builds to protect against code injection attacks. Thanks for following up. |
This makes the compile-time dependency on google-java-format optional.