checkstyle.xml fits rather well as output format for nearly any linter or code analyzer and unlike custom formats, it's well understood by some existing tools, e.g. Jenkins plugins, so by reporting errors in this format it's possible to achieve better integration with various existing tools, for example our pipeline is capable of reporting entries from checkstyle.xml into a corresponding pull request which is very convenient.
There are several obvious ways to achieve this goal:
add checkstyle.xml support into this linter;
write a converter from JSON to checkstyle.xml as a standalone tool.
I'm not sure which way would work out better. What do you think?
119 is a quick and yet untested (in code; reports are generated just fine) try to implement the former approach; I wonder if it's worth working on (i.e. if maintainers are interested in merging checkstyle support), if not – I'll just go for a standalone converter.
checkstyle.xml fits rather well as output format for nearly any linter or code analyzer and unlike custom formats, it's well understood by some existing tools, e.g. Jenkins plugins, so by reporting errors in this format it's possible to achieve better integration with various existing tools, for example our pipeline is capable of reporting entries from checkstyle.xml into a corresponding pull request which is very convenient.
There are several obvious ways to achieve this goal:
I'm not sure which way would work out better. What do you think?