-
Notifications
You must be signed in to change notification settings - Fork 134
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
baseline-format: can format build.gradle files #1561
Conversation
Generate changelog in
|
@@ -0,0 +1,3 @@ | |||
org.eclipse.jdt.core.formatter.tabulation.char=space | |||
org.eclipse.jdt.core.formatter.indent_empty_lines=false | |||
groovy.formatter.remove.unnecessary.semicolons=true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a trial run with this config on devx/template-witchcraft and it makes zero changes!! I didn't quite believe it, so I indented stuff like crazy and it restored it :)
The unit-test-15 errors are unrelated, put up a fix in #1565. But don't think we need to block on this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I love it!
Will the excavator also be opt-in? I think its fine to just always let the excavator reformat the gradle files but maybe that's what you are already intending to do :)
Released 3.55.0 |
Before this PR
Every now and again, we stumble across some elaborate build.gradle files full of custom stuff. These are sometimes hard to read due to each project's own idiosyncratic styling opinions.
Well it turns out spotless can just zap em all with a consistent format!
After this PR
==COMMIT_MSG==
com.palantir.baseline-format
now understands how to format build.gradle files. This is opt-in by default, so you need to run./gradlew format -Pcom.palantir.baseline-format.gradle-files=true
to try it, or add this property to your gradle.properties if you want to lock it in.==COMMIT_MSG==
I've intentionally made this opt-in because I'm intending to write an auto-merging excavator which will just come round and re-format your files, without incurring the annoyance of failing builds because someone has got their indentation wrong.
Possible downsides?