Apply Palantir Java Format to the entire codebase + enforce on every build#1773
Merged
Conversation
This is a mechanical reformat of every .java file under src/ via the Palantir Java Format style. There are no behavior changes. The follow-up commit adds the Spotless Gradle plugin that produced this output, wires it into the build as an enforcement step, updates the contributor docs, deletes the obsolete java-style-eclipse.xml and java-style-intellij.xml style guides, and adds .git-blame-ignore-revs so this commit is skipped by `git blame`. The single non-mechanical change in this commit is the removal of one stray "// the imports for unit testing." comment from VariantContextUnitTest.java that was preventing the formatter from treating the surrounding imports as a contiguous block. The comment carried no information. Part of #1761.
…1761) All build, CI, and contributor-facing changes for the new code-style enforcement. The bulk reformat itself is in the previous commit; this commit only contains setup. build.gradle: - Add the com.diffplug.spotless plugin (8.4.0), configured with palantirJavaFormat() over src/**/*.java. There are no formatter knobs -- the formatter is the style guide. - Make compileJava depend on spotlessJavaApply so any unformatted source is auto-rewritten in place during the build. Contributors don't have to remember to run a format command -- just build, and the source ends up formatted. spotlessJavaApply is sub-second warm thanks to Gradle's up-to-date checking, so the cost on every build is negligible. .github/workflows/tests.yml: - Add a `formatCheck` CI job running `./gradlew spotlessCheck` (verify-only, no mutation) so unformatted code can't slip past CI. The local auto-format is a convenience; CI is the enforcement boundary. CONTRIBUTING.md: - New "Code Style" section: how the auto-format works, when/why you might still want to run `spotlessApply` directly, that CI verifies rather than rewrites, and how to opt in to .git-blame-ignore-revs locally. .git-blame-ignore-revs: - New file pointing at the bulk-format commit so `git blame` (and the GitHub web blame view, which honors the file automatically) credits the original author of each line rather than the reformat commit. Deletions: - java-style-eclipse.xml and java-style-intellij.xml -- stale, unreferenced by the build, and inconsistent with Palantir's output. Closes #1761.
Member
Author
|
Fixes #1761 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #1761.
This is a doozy on purpose: it brings every
.javafile in the repo under a single mechanical code style (Palantir Java Format) and wires up the build so the codebase stays that way going forward.The PR is structured as two commits, no squash, so both flow into
dev:Apply Palantir Java Format to entire codebase— 1155 files reformatted. No behavior changes. The single non-mechanical edit is the removal of one stray// the imports for unit testing.comment inVariantContextUnitTest.javathat was preventing the formatter from treating an import block as contiguous.Add Spotless + Palantir Java Format and auto-format on every build— adds the Spotless Gradle plugin configured withpalantirJavaFormat(); hooksspotlessJavaApplyintocompileJavaso local builds auto-rewrite unformatted source in place; adds a CIformatCheckjob that runsspotlessCheck(verify-only) as the actual enforcement boundary; adds aCode Stylesection toCONTRIBUTING.md; adds.git-blame-ignore-revspointing at commit 1; deletes the stalejava-style-eclipse.xmlandjava-style-intellij.xml.Local DX
Local builds fix formatting rather than fail on it -- contributors don't need to remember to run a formatter command. CI separately verifies (no mutation), so unformatted code still can't slip into
dev.spotlessJavaApplyis sub-second warm thanks to Gradle's up-to-date checking, so the cost on every compile is negligible.Git blame
.git-blame-ignore-revspoints at the bulk-format commit. GitHub honors it automatically in the web UI. Locally, run once per clone:This is documented in the new
CONTRIBUTING.mdsection.Test plan
./gradlew compileJava compileTestJava-- passes./gradlew test-- 21,936 / 21,936 pass./gradlew spotbugsMain spotbugsTest-- cleancompileJavarewrites unformatted source in place (smoke-tested on a deliberately-malformed file)git blamewith--ignore-revs-file .git-blame-ignore-revscredits the original authors, not the reformat commitformatCheckjob is greentest/testExternalApis/spotBugsjobs still green