Paul,
I have created a patch that might be of some use to other Macker
users. The patch adds the name of the pattern to each violation in the
violation report. Instead of only seeing from class to class, the name of
the pattern is also added so that you can see which pattern is involved
in the rule violation.
A coworker of mine, Michael Sassin, and I use the patterns to define
modules and the rules to enforce dependencies between the modules.
This patch helps identify classes that are not part of a pattern/module or
classes that might be a part of two different patterns/modules.
The XML generated looks like:
<access-rule-violation severity="error">
<message>Violation of rules in module in "common-utils"!</
message>
<from module="common-utils">
<full-name>a.b.c.SomeUtil</full-name>
<class>SomeUtil</class>
<package>a.b.c</package>
</from>
<to module="top-level-module">
<full-name>a.b.d.TopLevelClass</full-name>
<class>TopLevelClass</class>
<package>a.b.d</package>
</to>
</access-rule-violation>
This is a patch against the CVS repository. Here's a summary of the
changes:
AccessRuleViolation - I added the EvaluationContext to the violation so
that when when a violation is encountered, I can essentially re-run the
rule test when the XmlReportingListener executes. This seems like
somewhat of a hack... but it works. Maybe you know of a better way to
implement this.
XmlReportingListener - I added a new method called
findModuleName that uses the EvaluationContext from the
AccessRuleViolation to find the name of the module for the from and to
classes.
RuleSet - Added a method to return all of the patterns (module names)
RecordingTest - seems to fail on Windows. Made simple fix.
html-basic.xsl - Added the module to the HTML report.
Logged In: YES
user_id=41726
duplicate of 1347443