Update dependency org.slf4j:slf4j-nop to v2

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
org.slf4j:slf4j-nop (source, changelog)	1.7.36 → 2.0.17

---

Configuration

📅 Schedule: Branch creation - "before 4am on Monday" in timezone CET, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonar-review-alpha]

Summary

A migration of the SLF4J no-op logging implementation from the 1.7.x line (1.7.36) into the treacherous lands of version 2.0.17. This is no mere patch — it is a passage from one age to another, a major version leap that the Fellowship of this codebase has not yet ventured. The change touches but a single dependency declaration in the Rule API Gradle configuration, yet its ripples may extend far into the realm of the build and runtime. One line altered; the compatibility of the entire logging strategy hangs in the balance.

What reviewers should know

What Requires Your Scrutiny: SLF4J v2 introduced significant changes to the API surface, including Java Platform Module System support and revised package structures. Though this particular artifact is slf4j-nop (a silent sentinel that performs no logging), you must verify that no other dependencies in this project demand the 1.7.x line of SLF4J. Seek out the dependency tree — gradle dependencies or similar incantations will reveal if this change cascades through the entire fellowship. Should other logging bindings (logback, log4j2, or others) remain anchored to version 1.7.x, you may face profound conflicts that will break the build itself.

The Path Forward: Test this build in its entirety. The gradle modules must compile without shadow or deception. The rule API itself, which depends upon this no-op logger, must function as expected. Pay heed also to any integration or acceptance tests that may lurk in the depths — they may reveal incompatibilities that the compiler would not.

Watch for These Signs of Darkness: Version conflicts in the final dependency tree, module resolution failures during build, any warnings from the SLF4J bridge that suggest a mismatch between the logging API and its implementation.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

---

• 🐟 April Fools' persona mode!

[sonarqube-next]

Quality Gate passed for 'cloud-native-gradle-modules'

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

[sonar-review-alpha]

Conclusion

A simple road on its surface, yet a perilous crossing may lie beneath. The version has changed, but whether the ancient purpose still holds is a matter worth confirming before the gates are opened.

🗣️ Give feedback

[sonar-review-alpha]

The because() comment that follows this line tells the whole tale of why this dependency exists: to silence a logging warning by providing a binding. Yet SLF4J v1 and v2 are not the same road — they bind their backends through entirely different mechanisms. In v1, the framework searches for org.slf4j.impl.StaticLoggerBinder on the classpath. In v2, it relies upon Java's ServiceLoader via META-INF/services/org.slf4j.spi.SLF4JServiceProvider. A slf4j-nop of version 2.x provides only the v2 service entry — it does not conjure up the old v1 binder.

Should com.sonarsource.rule-api:rule-api:2.19.0.5763 still carry a transitive dependency on the SLF4J 1.x API, this upgrade will not silence its warnings as intended. The very reason this dependency was placed here would be undone — silently, without error or fanfare. Verify that rule-api's transitive closure has itself crossed into SLF4J 2.x before approving this passage. Running ./gradlew dependencies --configuration ruleApi and inspecting the SLF4J lines in the output will reveal the truth.

• Mark as noise