Checkstyle suppress file generator

There is interesting patch/tool to Checkstyle that generate supppress.xml file base on all existing violations that are now in code, issue, patch with description.
In description there is only reference to legacy code that nobody want to fix now and team want to proceed forward with validation of new code only.

Documentation for Checkstyle suppression filters are here.

In JulioG approach there are two problems:
- if legacy code is frozen (separate project or packages).
In that case it is easier to do hard suppress on files and folders see example below.

- if legacy code still in active project, and it is expected and some changes might appear.
In that case current suppression approach could hide problems that appear in new code. Existing Suppression mechanisms are not ideal and bound to line numbers any changes to that file will make all rules as irrelevant and incorrect. That will cause more problem. So I to not recommend this !!!

Example for whole folder/file suppression in suppress.xml file:

<suppressions>
....

<!-- suppress folder -->

<suppress checks=".*" files="org[\\/]apache[\\/]cassandra[\\/]thrift[\\/]" />

<!-- suppress all integration tests in certain package -->

<suppress checks=".*" files="com[\\/]company[\\/]runner[\\/].*IT.java" />

<!-- suppress all in legacy files -->

<suppress checks=".*" files="LegacyBuilder.java|LegacyReloader.java|LegacyTester.java" />

...

</suppressions>

But suppress file generation have another reason to exists:
- upgrade to new Checkstyle version should not block build or fail Jenkins configuration, or  make SonarQube unhappy.
New Checkstyle release will always introduce bug and problems and false-positives fixes. So after most of upgrades to new Checkstyle some problems could appear. New Checks for sure will highlight your code :). If you use SCM hooks, Jenkins, ..... for code validation base on commit that will fail or stop the whole build-deploy process that is not desirable.

Proposed workflow:
- Code is clean;
- Plan to upgrade Checkstyle(or turn ON new Checks), generation of suppress file for new violations that are introduced by new version;
- Code is clean;
- Upgrade Checkstyle or turn ON new Checks;
- Code is clean;
- Resolving temporal suppression as separate task/step; removing all newly created suppression from suppress config.
- Code is clean;

That will give you some time to fix new violations as separate step, and resolving Checkstyle will be planned and not block anybody. But never have such suppression generations for long period it will over-complicate your configuration and will not resolve problem you tried to tackle.


PS: suppression model in Checkstyle need to be improved to be not bound to line numbers or ....