Override slf4j-api version

[TheForbiddenAi]

Currently, the Reflections library pulls in slf4j-api 1.7.36. This means applications using the gauge-java plugin are unable to use log4j2 without dealing with dependency conflicts. Given that the Reflections library is no longer maintained, I suggest we override the slf4j-api version to 2.0.16

[chadlwilson]

I'm not totally averse to this, but which dependency "conflicts" are you referring to?

If they have their own dependency on a newer slf4j it will take precedence and override the transitive, and you can use log4j2 with either slf4j version to my knowledge?

It might break any folks still relying on slf4j 1.7 and logging backends tied to that, but I dont think that's a major concern as I guess they can force a downgrade.

[TheForbiddenAi]

While I believe in Maven that is the case, Gradle requires a dependency resolution block to resolve the conflict between slf4j 1.7 and slf4j 2, and it would be ideal not to have to include that in all of our projects. You are right in that it can be used with both, I misspoke on that. However, it requires using an additional dependency for the bridge that we would otherwise get elsewhere for slf4j2. We are trying to avoid as much boilerplate as possible. Additionally, due to the way we use gauge within our services, it would also be less than ideal to add these

[chadlwilson]

Can you be more specific please?

Slf4j 1 and 2 use the same org.slf4j:slf4j-api co-ordinates and maven’s nearest definition resolution vs gradles highest version resolution shouldnt play a major difference here if you already have your own dependency on slf4j in your consuming project.

You’re asking this project to take on the risk of version conflict/issue with reflections by overriding a transitive dependency to a version it doesn’t declare it is compatible with, in a way that may break other users, so it’s probably best to clearly explain the problem you have, what you have tried to resolve it and your use case so an appropriate trade off can be made.

[TheForbiddenAi]

The exact error we are seeing is

Could not resolve org.slf4j.slf4j-api:1.7.32
Required by:
     project : > com.thoughtworks.gauge:gauge-java:0.11.2 > org.reflections:reflections:0.10.2

As of now, we are using a gradle dependency resolution strategy to force all usages to version 1.7.32. Forcing the version is not ideal given the number of libraries we use that have a dependency on slf4j. Ideally, we would open a PR with the reflections library but it is unmaintained.

Our end goal is to be able to use the latest version of slf4j and reduce the amount of boilerplate code. We understand if you do not want to take on this risk and will continue to evaluate other approaches if needed.

[chadlwilson]

The reason/additional context for the error appears to be omitted above so can't give much insight. There must be something else in your project that is causing a resolution error like that, or you perhaps have conflicting rules from other library/plugin, or have expressed other constraints which cannot be met.

Do you have a minimal reproducing example? What does the dependencies tree look like for the relevant configuration (e.g testRuntimeClasspath).when you use it the way you want to? Vs what works? What does your resolution strategy that 'fixes it' look like, specifically?

I think the challenge I am having is that you have proposed a solution directly here before clearly defining a problem that can be seen by others to be wider than some quirk of your specific Gradle usage. I don't understand what you could be doing to be getting a resolution error like that. I have seen that only a handful of times in quite a number of years of using Gradle, and usually with complex manual exclusions or constraints or module remapping or messy multi-project setups.

[TheForbiddenAi]

I can't provide much more information due to a variety of reasons, but I do agree that it is most likely a quirk of the way we are using gradle. So, I will close the PR

[chadlwilson]

That's unfortunate because I'm happy to help, and have extensive Gradle dependency mgmt experience via https://github.com/gocd/gocd which uses basically every Gradle trick in the book in a multi-project fashion (module replacements, exclusions, constraints via platforms, direct constraints, resolution rules) 😅