To answer my own question:
https://maven.apache.org/scm/maven-scm-plugin/check-local-modification-mojo.html

T


On Thu, Oct 13, 2022 at 9:47 AM Tamás Cservenák <ta...@cservenak.net> wrote:

> Howdy,
>
> to not get lost in implementation details, it is really unimportant
> (spotless, this or that...)
>
> What IS important is that we agree to implement "IDE agnostic source
> formatting", that happens during build
> (by maven plugin). This means _everyone_ will end up with 100% the same
> result.
>
> The only thing that comes to my mind is "sloppy committer" who does not
> build but pushes....
> Is there some option to have a profile (activated on CI) that detects
> there are "uncommitted changes" post build?
> As that would mean that sourcetree contains sources NOT formatted, and
> that CI build did reformat them...
>
> But even without this step mitigation is simple: someone just rebuilds
> HEAD and commits...
>
> Thanks
> T
>
> On Thu, Oct 13, 2022 at 8:41 AM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
>> 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
>>> >
>>>
>>

Reply via email to