SONARCH-708, SONARJAVA-5497: Extend SonarJava CheckRegistrar API for registering custom file scanner hooks

[kaufco]

SONARCH-708

[dorian-burihabwa-sonarsource]

I think the change looks simple enough to integrated as-is, but there are a couple of questions I have left for you to look at.

In addition, I thin that he ticket attached to this PR should be a SONARJAVA ticket because this change implies a modification of the public API and should be properly documented as part of the release

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[dorian-burihabwa-sonarsource]

I think what bothers me most is the need to test an empty method and the lack of guidance for what a good implementation of registerCustomFileScanner should look like.

After discussing with @kaufco, it looks like we have 2 options to improve the current proposal.

1. Improve the documentation of the new method to describe what a good implementation of registerCustomFileScanner should do and keep the test of the of the empty method (with a name that indicates that there is no expected behavior of the default implementation)
2. Enforce some sort of contract by setting a return type and/or an exception type to registerCustomFileScanner

My preference goes for option 2 because it enables us to write a test where we can implement a child class and test what the default behavior is.

@Test
void registerCustomFileScanner_default_implementation_returns_expected_value() {
  class Child extends CheckRegistrar.RegistrarContext {
    // Nothing overridden here
  }
  var context = new Child();
  assertThat(context.registerCustomFileScanner(null, null)).isEqualTo(EXPECTED_VALUE);
}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
97.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[leonardo-pilastri-sonarsource]

LGTM, let's just change the test in SonarComponents to an end-to-end check that the scanner is actually invoked when registered through the new API

[dorian-burihabwa-sonarsource]

Thanks for coming back to this. I just left a question about the Javadoc and a small typo

[dorian-burihabwa-sonarsource]

will have no effect: meaning that it is safe to report and not trigger any issue at runtime?

[kaufco]

Exactly. There's also a test for this. Reason: there was a null check somewhere in the implementation chain of reportIssue / addIssue (I don't remember in which class/function exactly) triggering the underlying low-level function only if ruleKey != null, doing nothing otherwise.

[dorian-burihabwa-sonarsource]

Suggested change

	CheckRegistrar registrar =registrarContext ->
	CheckRegistrar registrar = registrarContext ->

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
97.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube