+1, BUT in addition to Hervé's answer: Create a file '.git-blame-ignore-revs', which seems to be a common convention: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-with-git-blame
This way, we can see CODE changes via diff/blame without those nasty formatting changes. --- For the formatting, I can really recommend the spotless-maven-plugin in combination with the eclipse formatter, which can be fine-tuned in a very nice manner. It also supports "ratchetFrom" configuration, i.e. only blame changes from the current commit. Checkstyle configuration can then be minimized to things like improper imports, header checks, N° of return statements etc. which are not handled by spotless. Am So., 16. Okt. 2022 um 10:23 Uhr schrieb Hervé Boutemy <herve.bout...@free.fr>: > > only one concern: clarify our convention for the initial reformat of any Git > repository so that it works with git blame --ignore-revs > (I hope current tools support for this feature is good enough nowadays) > > Regards, > > Hervé > > Le vendredi 14 octobre 2022, 10:41:30 CEST Guillaume Nodet a écrit : > > So here's my new proposal. > > > > I've already merged the two first PRs which did not change anything, as > > they were just about moving the existing resources (eclipse and intellij > > xml config) from the website to maven-shared and updating the website. > > > > I've updated the two interesting PRs to use spotless, relying on the > > existing format config now available from maven-shared-resources. The > > relevant commits can be seen at [1] for maven-core and [2] for > > maven-resolver. They add two profiles, the first one will check the > > source formatting, while the second will reformat the sources. By default, > > the first one (check) is activated, and if you pass -Dformat or -Pformat to > > the command line, the second profile (format) is activated and used > > instead. In the same commit, I've deactivated a few checkstyle checks > > which are enforced by spotless, so the remaining checks are not about code > > formatting, but rather method/file length, naming, etc... > > They are followed by big reformat commits to restore all files to the > > enforced coding style. The related PRs are [3] and [4]. > > > > I think this alleviates the concerns that were raised, so if there's no > > objection, I plan to slowly move all projects to use that. Or even better, > > release a new maven parent with the needed changes and simply upgrade the > > projects. However, the change would be done after the discussion on > > changing the coding style has settled so that both things would be done at > > the same time. > > > > Any concerns ? > > > > Guillaume > > > > [1] > > https://github.com/apache/maven/pull/824/commits/f1aa72b1dd0fc934417e7f1ca80 > > 027de0fc0d036 [2] > > https://github.com/apache/maven-resolver/pull/147/commits/4ae0de301fcf2d9f85 > > 09a9a6564c840aa0815258 [3] https://github.com/apache/maven/pull/824 > > [4] https://github.com/apache/maven-resolver/pull/147 > > > > Le mer. 12 oct. 2022 à 18:23, Guillaume Nodet <gno...@apache.org> a écrit : > > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
