slf4j-api in httpcomponets-testing module is set to a wrong dependency scope.

[HappyHacker123]

Problem Description

The slf4j-api is declared without assigning a dependency scope, leading to a default scope compile. But it's only used for testing with classes [org.slf4j.Logger, org.slf4j.LoggerFactory] in file “TypeAsyncResources.java" and "TestClientResources.java".

    <dependency>
      <groupId>org.slf4j</groupId>
      <artifactId>slf4j-api</artifactId>
    </dependency>

Possible Outcome

This brings redundant compile time dependency for the module, increasing the probability of dependency conflict for downstream users.

Solution

Changing the dependency scope to test can help. After changing the dependency scope to "test," I recompiled the module and executed the tests. Following these adjustments, the module compiled successfully, and all the tests passed.

[HappyHacker123]

@ok2c @arturobernalg Could you look at these changes? Thx :p

[Sharofiddin]

This project by itself for testing, I think this change is redundant.

[HappyHacker123]

This project by itself for testing, I think this change is redundant.

Thanks for your reply :) .

However, I think how downstream users use this project wouldn't hinder keeping a clean dependency tree. As maven official document goes, dependencies used for tests should be in test scope. Setting slf4j-api to test scope seems to do no harm.

What's more, declaring a dependency as "test" scope means that the dependency won't be transitive according to maven doc, which means that this dependency won't be propogated to downstream users that use this project, even if the project is used for test by downstream projects. Scope "compile" is just the other way round.

[ok2c]

@HappyHacker123 httpclient5-testing depends on httpclient5 that will drag in slf4j-api as a transitive dependency with compile scope no matter what. I agree though there is no harm in making the scope explicit even it has no effect on the real dependency graph.