On Thu, 13 Oct 2022 at 02:23, Guillaume Nodet <gno...@apache.org> wrote: > > 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.
As far as I can see Intellij supports import from checkstyle. Eclipse? checkstyle should be the root/original format as it will be used by checkstyle:check. What if the intellij plugin does not integrate the last eclipse xml format changes etc... I would prefer we focus first on the cli tools (checkstyle and/or spotless) so there is no question of IDE configuration files interop. It's probably better to focus on tools available for everybody. (people can use netbeans, vsc etc...) format issue just use spotless:apply and voila. (no need to waste time finding the last IDE plugin which supports the new format from the other ide etc..) Please read me correctly. I do not say it's useless :) I just say it shouldn’t be the priority to focus on eclipse xml format. > > 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