Hi Gary, On Wed, 20 Sept 2023 at 16:23, Gary Gregory <garydgreg...@gmail.com> wrote: > Hmm... interesting but I can't help but think that we are making our > build more complex by jumping through hoops to fix problems of our own > making: We already use spotless in the builds. Now we want to use > OpenRewrite but that makes a "mess", so now we want to use _another_ > plugin to fix that, that in itself is a mess IMO. My favorite way to > deal with formatting and refactoring is to use Eclipse which has a > large set of formatting configuration options and clean-ups. Not > everyone uses Eclipse, so sharing an Eclipse or any other IDE > formatter config might be pointless. I think we need to keep > refactorings OUT of builds, formatting is already weird enough.
Sure, I don't plan to add refactorings into the builds, but if we do use OpenRewrite locally we need a way to fix the formatting problems caused by the refactoring. The current Spotless configuration does not do it. Spotless supports many formatter plugins, the main ones being Eclipse, Google and Palantir formatters. All three are IDE agnostic. I like the idea of using a non-configurable one, since it is a binary choice, but the Eclipse formatter is a great tool with literally hundreds of options. As long as we don't have to discuss every option and the options that bloat the line length (like "align field initializers") are off, I am fine with it. Could you maybe add your formatter's configuration to `logging-parent` so that we can evaluate how it formats code? Piotr PS: I can submit an option to Spotless, so that package `foo` is ordered before class `FooBar` (as the Eclipse IDE does it). Spotless right now only uses `String.compareTo`.
