I don't think it's a bug, your violationSuppressXPath just returns true all the time. Remember, that it's evaluated with the violating node as the context node of the expression.
//ClassOrInterfaceDeclaration
//
at the start of an XPath expression select all the descendants of the document root, so all the nodes in the file. So //ClassOrInterfaceDeclaration
selects all the nodes of that type in the file, and not necessarily one that encloses the violation node.
['.*PrincipalRepository']
This predicate is always true, because any non-empty string is truthy. A predicate like ['foo']
is evaluated by converting the string to a boolean with the boolean
function, which yields true()
if the string is non-empty. (Here you mean to test the name of the class, in the attribute @Image
)
So basically the predicate doesn't test anything. The effect, is that your violationSuppressXPath
suppresses the violation any time the file where the violation is found contains some ClassOrInterfaceDeclaration anywhere, which is pretty frequent.
To make this work, you could replace it with
./ancestor::ClassOrInterfaceDeclaration[@Image = 'PrincipalRepository']
Note that unfortunately, XPath 1.0 does not support regular expressions so you can't do a regex test (though you can use contains
or imitate an ends-with
like in this answer). In this instance, I think a @SuppressWarnings("PMD.MethodNamingConventions")
like you came up with is more appropriate.