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
