Howdy, to not get lost in implementation details, it is really unimportant (spotless, this or that...)
What IS important is that we agree to implement "IDE agnostic source formatting", that happens during build (by maven plugin). This means _everyone_ will end up with 100% the same result. The only thing that comes to my mind is "sloppy committer" who does not build but pushes.... Is there some option to have a profile (activated on CI) that detects there are "uncommitted changes" post build? As that would mean that sourcetree contains sources NOT formatted, and that CI build did reformat them... But even without this step mitigation is simple: someone just rebuilds HEAD and commits... Thanks T On Thu, Oct 13, 2022 at 8:41 AM Tamás Cservenák <[email protected]> wrote: > Formatting happens during build, so once merged all we need is to merge > master into PR branches... > > T > > On Thu, Oct 13, 2022 at 8:40 AM Sylwester Lachiewicz < > [email protected]> wrote: > >> What about already open PR with some features or bug fixes. >> Don't we should review and merge it before reformatting code - otherwise >> we >> will have lots of merge conflicts and over time no one will have energy to >> review it? >> >> Sylwester >> >> śr., 12 paź 2022, 18:23 użytkownik Guillaume Nodet <[email protected]> >> napisał: >> >> > I'd like to propose merging the following PRs: >> > * https://github.com/apache/maven-shared-resources/pull/1 >> > * https://github.com/apache/maven-site/pull/329 >> > * https://github.com/apache/maven/pull/824 >> > * https://github.com/apache/maven-resolver/pull/147 >> > ... and more to come >> > >> > The idea is to use plugins to automatically reformat the source code and >> > sort imports to obey the maven coding style. >> > The first PR adds the necessary resources to maven-shared-resources : a >> new >> > header file, as there's a requirement to put the header at the very >> > beginning for the import sorter plugin to work correctly (else it >> considers >> > the license comment to be part of comment headers and screws the >> > formatting), and the eclipse xml formatter plugin. >> > The second PR updates the web site to point to that file which would be >> in >> > git instead of on the maven web site, and also updates the instruction >> for >> > IDEA since it has been supporting the eclipse xml config for years now). >> > The third and fourth PRs are updates on maven and maven-resolver to >> apply >> > those two plugins. >> > >> > Those plugins have been used on mvnd and maven-build-cache-extension >> > already, although they are not using a single shared resource that >> would be >> > added by the first PR. Hence mvnd is still using its previous coding >> > style. >> > >> > Another point is that those plugins are fast and only do not process >> files >> > if they have been already processed and untouched since the last >> build. So >> > from a daily development pov, this is transparent and does not incur any >> > additional processing time during the build (or not much really). >> > >> > Cheers, >> > Guillaume >> > >> >
