As i used Checkstyle as a component in a the implementation of more larger J2EE code-verification tools, i stumbled on a limitation of the product.
Before this implementation, we wrote a documentation that describs 250 rules of programmation for J2EE project. Each rule are written with a specific syntax such as:
"[RULE-1] You should not do this..."
We wanted the tool to generate report including the original message from the document and not the basic message from checkstyle.
It's possible ( i tried it) to "override" the message from the checkstyle-XX-.jar but it's not very clean, and it does not really solve the problem.
The trouble is : we seldom use one check, with a different configuration, to handle SEVERAL rules from the document, plus, we some time use severals checks to handle just ONE RULE from our document. As it is now, the generated report offers no way to tell wich violation break which of our rules...
A very simple way of doing this would be to just to add a property in 'AbstractViolationReporter', such as 'label', wich could be set in the checkstyle configuration file as an optionnal attributes :
<module name="LeftCurly"> <property name="tokens" value="CLASS_DEF,INTERFACE_DEF,METHOD_DEF,CTOR_DEF"/> <property name="option" value="nl"/> <property name="label" value="[RULE-1]"/> </module> <module name="LeftCurly"> <property name="tokens" value="LITERAL_CATCH,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE"/> <property name="option" value="nlow"/> <property name="label" value="[RULE-2]"/> </module>
Finally just propagate this data if the label field is set :
<error line="x" label="<span>[RULE-2]</span>" column="y" severity=".." message="..." source="..."/>
This way the feature will not have an impact in case of migration, it'll be quite easily done ( i believe) and we will have a way to XSL-out our way of the problem...