The basic idea is to introduce that with a new parent pom. Once a module adopts this new parent version, it needs to manually reformat everything once to not fail the build. This is a one time effort together with updating to the new pom. Therefore it requires some opt-in per module anyways. Konrad
> On 6. Dec 2023, at 10:53, Stefan Seifert <stefan.seif...@diva-e.com.INVALID> > wrote: > > i like it to have tooling like this around (but if have no experience with > this tool). > > one important point is that e.g. for PRs it only validates newly added lines. > if all PRs fail due to inconsistent formatting in the existing codebase this > would be quite disruptive. > > stefan > >> -----Original Message----- >> From: Konrad Windszus <k...@apache.org> >> Sent: Tuesday, December 5, 2023 9:18 PM >> To: dev@sling.apache.org >> Subject: Introduce spotless-maven-plugin >> >> Hi, >> We never had any formalised code formatting rules nor ever provided any >> formatters for different IDEs (at least not that I am aware of). >> That often leads to undesired formatting changes in PRs. >> I propose to introduce >> https://github.com/diffplug/spotless/tree/main/plugin-maven to >> automatically enforce certain formatting rules during build (as well as to >> optionally apply those). >> >> There are quite some built-in rule sets. >> Apache Maven uses https://github.com/diffplug/spotless/tree/main/plugin- >> maven#palantir-java-format and >> https://github.com/diffplug/spotless/tree/main/plugin-maven#maven-pom >> quite successfully for a while now. >> >> I am open to using another rule set, but the important bit is that we can >> enforce that across different IDEs easily during the build and fixing is >> easy for contributors/committers as well. >> >> WDYT? >> >> Konrad
