apply spotlessApply on dev environment

[Pankraz76]

Overview

if there is the glance of autofix why not automatically apply it. Might be worth to save time, just as quarkus, maven and PMD have done their setup that way.

Currently its breaking the build for whitespaces having to run some random command (spotlessApply) to fix.

have (break build):

want (fix build):

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[marcphilipp]

Since the Eclipse formatter we use isn't perfect, we sometimes want to manually format code using // @formatter:off/on comments or avoid lines from being collapsed using // at the end of them. Making applying and checking the formatting locally the same step would break that workflow. Rather than blindly calling spotlessApply, I often look at the offending code and decide whether I want to fine-tune it using one of the strategies described above. Therefore, I don't think we should merge this PR.

@Pankraz76 Thanks for the initiative, though!

[Pankraz76]

if you run the goal yourself, as you have to, instead not to waste time, or having it automated, i dont see any difference except of having the CoC burden fixed.

Checking the diff before commit is ether way a good idea to do.

There is not such thing as perfect, so its always double checked on small diffs.

[Pankraz76]

Eclipse formatter

why not use palantir, like maven, or google?

Its again about convention over config and cost of carry simply fixed by choosing common default over custom config.

[marcphilipp]

Switching to a different formatter would mean reformatting the entire codebase and make Git history harder to read so it comes at a price that would need to be justified. I've used Palantir's formatter in other projects. It's better at some things but I also found its output weird at times.

[sbrannen]

Switching to a different formatter would mean reformatting the entire codebase and make Git history harder to read so it comes at a price that would need to be justified.

I concur.

This topic has been discussed countless times over the years, and I do not foresee any need to reformat the code base and/or move away from Spotless (and Eclipse formatter settings).

From day # 1, we decided as a team that we do not ever want to discuss formatting issues or preferences, and that's why we settled on the status quo.

In summary, we have more important things to spend our time on.