Wildcards in rule configuration (S110)

[oliver (Oliver Goroll)]

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:

1. Is this the correct behavior of the rule or should subpackages be excluded?
2. Do I have to specifiy single and double wildcards to correctly exclude all packages (e.g. org.eclipse.gef.*, org.eclipse.gef.**)?
3. 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

[Quentin (Quentin Jaquier)]

Hello @oliver,

Thanks for the feedback.

From my understanding, the current behavior is, certainly not easy to grasp at first glance, but correct.
Maybe part of the confusion comes from the fact that we are always talking about excluding classes (fully qualified) and not packages. The file you reached during your investigation is the correct one and describes the expected behavior: org.eclipse.gef.* will match any class in the package org.eclipse.gef while org.eclipse.gef.** will match all classes underneath org.eclipse.gef (therefore including sub-package).

That being said, I fully agree that the status of the description is not good enough. I created a ticket (SONARJAVA-3472) to at least make sure that rules using WildcardPattern are documented.

interpretation of wildcards should be consistent across all tools and rules.

Ideally, yes, and in fact it would also be easier for us, being able to always re-use the same implementation. Still, for many reasons (historical, specific requirement, …), it is probably not the case today. We will eventually have a look and clean little by little, having the same behavior as often as possible, and making sure others behavior are clearly documented, but this takes time.

I hope this clarifies the situation.

Best,
Quentin