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

Reply via email to