Codecov Report

Attention: Patch coverage is 75.55147% with 133 lines in your changes are missing coverage. Please review.

Project coverage is 57.993%. Comparing base (6726113) to head (f4b47f8).
Report is 184 commits behind head on master.

@@               Coverage Diff               @@
##              master     #4202       +/-   ##
===============================================
- Coverage     57.996%   57.993%   -0.003%     
  Complexity      2334      2334               
===============================================
  Files            645       645               
  Lines          34578     34578               
  Branches        5976      5976               
===============================================
- Hits           20054     20053        -1     
  Misses         12366     12366               
- Partials        2158      2159        +1     

Hi @mernst, given this is so large of a change and impact it can have on existing pulls, maybe it can be approached in a separate way.

Here are my thoughts on it.

• First run com.github.hazendaz.maven:whitespace-maven-plugin:1.3.0:trim as that one is less intrusive (plugin I maintain) and I saw some trailing spacing in various files I've been in. I think this is less likely to cause issues with open PRs.
• I would break this up into change per module only so its not so large but do those back to back until done.

Just my food for thought, and I agree tags in any files are bad. Not very cross platform nice and its getting mixed by contributors is pretty frequent. If you don't already you may want to make sure to have plugin do this automatically after done so it doesn't happen again. Spotless maven plugin is probably best candidate to cover the files in fast way.

There are also some tricks, I've seen 'maven' team doing where they make git ignore the commits involved since they add little value and can be seen as a lot of noise. Not sure that is worth the effort or concern as one can ignore whitespace and this is same line stuff but worth noting that is possible with git.

I agree that use of Spotless is better than trying to manually enforce the style. It can also "ratchet": enforce formatting only for lines that have changed, so there are no irrelevant changes in the version control history. I'll leave applying the trim plugin and/or Spotless up to you.

This is no longer necessary since #4408 has been implemented. Thanks for the idea to use spotless for this!