We currently have the rule S110: Inheritance tree of classes should not be too deep active. It is possible to configure classes and packages which the rule should not count against the limit. We configured the rule to exclude
org.eclipse.gef.*, matching the example
java.fwkPackage.*. We were under the impression that all classes which are located
org.eclispe.gef including any subpackages are then excluded. However, a colleague got an issue because he derived from a class which is located in
org.eclipse.gef.tools. I inspected the source code of the rule which uses the class
org.sonar.api.utils.WildcardPattern and noticed that this class can handle double asterisks to denote any path (like in
/path/**/file.txt). Then, I have added
org.eclipse.gef.** to the list of filtered classes and the issue was resolved.
Since I didn’t find any documentation on how this rule handles wildcards or how wildcards in configurations are handled in general (from the rule implementation it is clear that all rules can interpret a configuration string any way the like) I’d like to ask some questions:
- Is this the correct behavior of the rule or should subpackages be excluded?
- Do I have to specifiy single and double wildcards to correctly exclude all packages (e.g.
- Were can I find documentation on wildcard behavior for rules in general?
This instance of unexpected behavior (at least for me) concerns only the rule S110, however interpretation of wildcards should be consistent across all tools and rules.
We are currently using SonarQube 7.9.1 and SonarJava 6.3