-
Notifications
You must be signed in to change notification settings - Fork 1.3k
commons-logging:commons-logging should not be a transitive dependency #1989
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I don't see where
Looking at the |
My bad. It was our own dependency on
Sorry for the noise. BTW, you can remove the |
ok, thanks for the info. I'll close this issue with the PR that will remove this exclusion later on |
I take that back. There is a problem, although it only occurs with Gradle. Unfortunately, Gradle doesn't apply Maven's own exclusion semantics when it's resolving dependencies using Maven's metadata (a pom file). Instead, it requires every path to a dependency to exclude it for the exclusion to be effective. In this case, there's a path through Could you please add an exclusion of |
The whole dependency to the transport client will be gone from the main branch with the next commit I'll merge in. So that will be automatically resolved by that. |
Thanks. Could you consider doing something similar in the active maintenance branches too please? It was the 4.1.x branch where I first saw this. |
there I need to add the exclusion, because the transport client is used in them, I'll do that for 4.1 and 4.2 then |
But what makes me wonder: why can't I see this dependency in maven? If I take out the existing exclusion, I can only see |
I think it's just due to the way that Maven shows you the dependency graph. |
I just created a project with the spring initializer (boot 2.4.12, that uses Spring Data Elasticsearch 4.1.12, gradle) and tried to see the dependency there. I ran |
I saw the problem in Spring Boot's build. If you remove this line |
Ok, I found it. So this problem will even persist when using the new upcoming Elasticsearch client, as this will replace the high level client but still will need the low level client (which is Apache 2 licensed, so it is no problem to use it). So I will add the exclusion in the current main to the high-level and low-level clients and in the 4.3 - 4.1 branches additionally to the transport-client dependencies. |
Excellent. Just in case it's still useful, here's a minimal Gradle script that shows the problem:
|
fixed in main, 4.3.x, 4.x.2 and 4.1.x |
Spring projects should use Spring Framework's
spring-jcl
module (a dependency ofspring-core
) in place ofcommons-logging:commons-logging
, howeverspring-data-elasticsearch
pulls incommons-logging:commons-logging
transitively. Can it please be excluded so that users don't end up with two different set of Commons Logging classes on their classpath?The text was updated successfully, but these errors were encountered: