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 <slachiew...@gmail.com> 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 <gno...@apache.org> > 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 > > >
