fix(deps): update dependency org.slf4j:slf4j-api to v2

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
org.slf4j:slf4j-api (source)	1.7.36 -> 2.0.7

---

⚠ Dependency Lookup Warnings ⚠

Warnings were logged while processing this repo. Please check the Dependency Dashboard for more information.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), 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 has been generated by Mend Renovate. View repository job log here.

[MartinWitt]

This PR is failing LogTest and maybe breaking. I have to ask why do we test a logging lib? Testing dependencies seems somewhat wrong, specially for logging. To my understanding, Log4J2 is an interface and any user of spoon can provide their backend if they like. Do I miss something?

[slarse]

This PR is failing LogTest and maybe breaking. I have to ask why do we test a logging lib? Testing dependencies seems somewhat wrong, specially for logging.

Well, the log tests aren't testing a logging library, they're testing that our implementation of logging is working as expected (with being able to set log levels and whatnot).

To my understanding, Log4J2 is an interface and any user of spoon can provide their backend if they like. Do I miss something?

Precisely, the backend used for the tests is a... test backend (uk.org.lidalia.slf4jtest.TestLogger). It's not entirely unlikely that it's misusing some internal implementation detail of SLF4J, because according to the release notes the 2.X release should be highly backwards compatible. And we don't do anything particularly exciting with logs.

[I-Al-Istannen]

The test logger seems to no longer be picked up by SLF4j, causing the default NOP fallback backend to be used. This, of course, breaks the tests. I didn't find any nice replacement, but apparently logback can do it (or you can do it yourself):
https://stackoverflow.com/questions/29076981/how-to-intercept-slf4j-with-logback-logging-via-a-junit-test

[I-Al-Istannen]

Do we plan to solve this PR? I am not sure if the test has enough value to block this PR. Updating the SLF4J bindings has user-facing impact we need to think about though.

[slarse]

@I-Al-Istannen I agree that the test itself is not enough value to block, but I feel unsure about how this affects consumers of Spoon. I frankly don't quite remember how slf4j works, but I'm guessing that a consumer using a logging implementation incompatible with version 2 would get breakage (much like the test, which is an incompatible implementation).

Then again, perhaps we should just always aim to move forward?

[I-Al-Istannen]

Judging by https://mvnrepository.com/, the share of slf4j 1 users seems to be quite a bit higher. I am not sure what we want here, it would be a breaking change for users.

[slarse]

Then I think it's quite evident that we hold off on this upgrade until its adoption is higher. Spoon as a project gains nothing from this upgrade, here it's really all about what the consumers use.

[MartinWitt]

Anyone against closing this PR because we won't merge this for a long time?

[renovate]

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 2.x releases. But if you manually upgrade to 2.x then Renovate will re-enable minor and patch updates automatically.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.