With the first patch, the fact that the source and message fields of the Violation seem to be reversed becomes more obvious. Specifically, the source is set to the error-text of the codenarc violation and the message is set to the codenarc rule that failed; but since Violation.getSource() strips everything before last dot, and the AbcComplexity messages are of the form "
The ABC score for method [foobar] is [92.0]", the result of getSource() is a useless "0]". Hence this second patch which reverses the source and message fields, which I think is semantically more correct.

Hi,
I can add these patches, but it may be easier if you got commit access and
maintain it. Just drop an e-mail on the hudson dev mailing list.

Peter

Good catch, my test bed project has the standard Grails rulesets configured ('rulesets/basic.xml,rulesets/exceptions.xml,rulesets/imports.xml,rulesets/grails.xml,rulesets/unused.xml') - had been planning to look at getting (standalone) GMetrics stats into Hudson this week.

Code changed in hudson
User: : peterkittreilly
Path:
trunk/hudson/plugins/violations/src/main/java/hudson/plugins/violations/types/codenarc/CodenarcParser.java
trunk/hudson/plugins/violations/src/test/java/hudson/plugins/violations/types/codenarc/CodenarcParserTest.java
trunk/hudson/plugins/violations/src/test/resources/hudson/plugins/violations/types/codenarc/CodeNarcXmlReport.xml
http://jenkins-ci.org/commit/35554
Log:
JENKINS-7271 patch for CodeArc parser does not parse AbcComplexity violations

Fix available since Aug/2010