SONARJAVA-6891 Remove redundant logging dependency handling

[vdiez]

Part of

Summary

• Remove redundant logging handling from Plugin API-bound code and the broad Renovate major-version exception.
• Keep dependencies explicit where source code directly imports SLF4J or Logback, with versions managed centrally and aligned with Plugin API v14.
• Preserve the standalone Vibebot SLF4J dependency and document its alignment requirement.

Validation

• mvn -pl java-frontend,docs/java-custom-rules-example,its/ruling -am test-compile -DskipTests
• Custom-rules logging tests: 3 passed.
• Dependency tree resolves SLF4J 2.0.18 and Logback 1.6.3.

[hashicorp-vault-sonar-prod]

SONARJAVA-6891

[vdiez]

The two remaining findings are addressed or intentional:

• The custom-rules example direct provided-scope SLF4J declaration is restored and centrally resolves to 2.0.18. Its dependency tree now contains SLF4J 2.0.18 with Logback 1.6.3, and the three previously affected logging tests pass.
• The broad Renovate major-version suppression intentionally remains removed. Vibebot is a standalone project that directly imports SLF4J, so it must retain an explicit dependency, but future major updates should be proposed and reviewed normally now that the platform supports SLF4J 2.x.

[gitar-bot]

Code Review 👍 Approved with suggestions 3 resolved / 4 findings

Consolidates logging dependency management under Plugin API v14, centralizing SLF4J and Logback versions and making direct imports explicit in java-frontend and the custom-rules example. Two prior findings on version hardcoding and incomplete test declarations have been resolved.

Consider either removing the standalone SLF4J pin from its/vibebot/pom.xml or restoring the Renovate packageRule scoped to that file, since the repo-wide major-update guard was dropped but the pin remains and is not covered by ignorePaths.

💡 Quality: Renovate SLF4J major-update guard dropped but a pin survives

📄 .github/renovate.json:6-12 📄 .github/renovate.json:57-66

The removed Renovate rule ("Major SLF4J version changes can create incompatibilities, so we prefer to update it manually") applied repo-wide, and its/vibebot/pom.xml still declares its own slf4j.version 2.0.18 property plus an explicit org.slf4j:slf4j-api dependency. its/vibebot/** is not covered by ignorePaths (which lists only docs/**, its/sources/**, its/plugin/projects/**, java-checks-test-sources/**, java-surefire/src/test/resources/**), so Renovate will now start proposing major SLF4J bumps for that pin — the exact case the deleted rule guarded. Either drop the standalone pin from its/vibebot (so nothing in the managed tree pins SLF4J) or keep the packageRule scoped to that file.

Re-add the guard narrowed to the one remaining explicit pin.

{
  "description": "Major SLF4J version changes can create incompatibilities, so we prefer to update it manually.",
  "matchFileNames": ["its/vibebot/pom.xml"],
  "matchPackageNames": ["org.slf4j:**", "org.slf4j"],
  "matchUpdateTypes": ["major"],
  "enabled": false
}

✅ 3 resolved

✅ Quality: Logging versions hardcoded per-module after central pin removed

📄 java-frontend/pom.xml:37-42 📄 its/ruling/pom.xml:23-28 📄 pom.xml:112-115 📄 pom.xml:274-280
This PR deletes the root pom's <slf4j.version>2.0.18</slf4j.version> property and the slf4j-api dependencyManagement entry, then re-introduces the same values as literal inline versions in two child poms (slf4j-api 2.0.18 in its/ruling, logback-classic 1.6.3 in java-frontend), while its/vibebot/pom.xml still carries its own slf4j.version 2.0.18. Because a direct declaration with an explicit version always wins over what sonar-plugin-api/sonar-plugin-api-test-fixtures bring transitively, the next plugin-API bump will silently leave java-frontend's tests on logback 1.6.3 and its/ruling on slf4j 2.0.18 while the fixtures move to a different pair — exactly the drift the removed root-pom comment ("The product must work with the SLF4J provided in the Plugin API") guarded against, and contrary to this PR's stated goal of relying on the plugin API to supply these versions. Manage the versions in one place (root dependencyManagement, test scope) and declare the module dependencies without a <version>.

✅ Quality: java-frontend declares logback-classic but not its other direct test deps

📄 java-frontend/pom.xml:37-42
The commit's stated rule is to declare dependencies used directly by test code, but java-frontend's ThreadLocalLogTester also imports ch.qos.logback.core.read.ListAppender and org.slf4j.LoggerFactory/org.slf4j.event.Level, and neither logback-core nor slf4j-api is declared in java-frontend/pom.xml — they are only reachable transitively (logback-core via logback-classic, slf4j-api via the provided sonar-plugin-api). The build still compiles today, but the module's declaration set is inconsistent with the rule this commit applies, so a change in either transitive path breaks the test compile with no local declaration to protect it. Add the two missing test-scoped declarations (version-managed centrally, see the other finding).

✅ Bug: Custom-rules example silently downgrades SLF4J to 1.7.30

📄 docs/java-custom-rules-example/pom.xml:25-39 🔗 plugin-api 10.12 -> slf4j-api 1.7.30 🔗 test-fixtures 14 -> logback-classic 1.6.3
docs/java-custom-rules-example pins sonar-plugin-api to 10.12.0.2522 (not v14), and that POM declares org.slf4j:slf4j-api:1.7.30 (compile, non-optional). Before this PR the module's own slf4j-api entry sat at depth 1 and took its version (2.0.18) from the root dependencyManagement, so it won Maven mediation. With that entry removed, the direct sonar-plugin-api:10.12 now supplies slf4j-api 1.7.30 to the module. Its tests (AvoidBrandInMethodNamesRuleTest, SecurityAnnotationMandatoryRuleTest) use org.sonar.api.testfixtures.log.LogTesterJUnit5, which arrives from sonar-plugin-api-test-fixtures 14.0.0.4498 together with ch.qos.logback:logback-classic:1.6.3 (runtime). Logback 1.6.x only implements the SLF4J 2.0 SLF4JServiceProvider service-loader binding and references SLF4J-2.0-only types, so against slf4j-api 1.7.30 the factory falls back to a NOP logger / NoClassDefFoundError and the log assertions break. So the removal is not redundant for this module — either keep the explicit pin here or move the module to plugin API v14.

🤖 Prompt for agents

Code Review: Consolidates logging dependency management under Plugin API v14, centralizing SLF4J and Logback versions and making direct imports explicit in `java-frontend` and the custom-rules example. Two prior findings on version hardcoding and incomplete test declarations have been resolved.
  
  Consider either removing the standalone SLF4J pin from `its/vibebot/pom.xml` or restoring the Renovate packageRule scoped to that file, since the repo-wide major-update guard was dropped but the pin remains and is not covered by `ignorePaths`.

1. 💡 Quality: Renovate SLF4J major-update guard dropped but a pin survives
   Files: .github/renovate.json:6-12, .github/renovate.json:57-66

   The removed Renovate rule ("Major SLF4J version changes can create incompatibilities, so we prefer to update it manually") applied repo-wide, and `its/vibebot/pom.xml` still declares its own `slf4j.version` 2.0.18 property plus an explicit `org.slf4j:slf4j-api` dependency. `its/vibebot/**` is not covered by `ignorePaths` (which lists only `docs/**`, `its/sources/**`, `its/plugin/projects/**`, `java-checks-test-sources/**`, `java-surefire/src/test/resources/**`), so Renovate will now start proposing major SLF4J bumps for that pin — the exact case the deleted rule guarded. Either drop the standalone pin from `its/vibebot` (so nothing in the managed tree pins SLF4J) or keep the packageRule scoped to that file.

   Fix (Re-add the guard narrowed to the one remaining explicit pin.):
   {
     "description": "Major SLF4J version changes can create incompatibilities, so we prefer to update it manually.",
     "matchFileNames": ["its/vibebot/pom.xml"],
     "matchPackageNames": ["org.slf4j:**", "org.slf4j"],
     "matchUpdateTypes": ["major"],
     "enabled": false
   }

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube