Elasticsearch container should not shade org.apache.http.HttpHost #958
Comments
|
Ouch, sorry, and thank you for reporting. We’re on it and will release a bugfix ASAP. |
|
OMG! This means that we are missing real integration tests then... |
That's an interesting point, testing the post shaded jar. Actually the examples Maven project kind of does this, but it not complete and it's not part of the Gradle build. |
|
Note that I was not able to reproduce because my own project depends on elasticsearch Java Client which brings httpcomponents deps... |
|
I'm pushing a branch which should fix the issue; will create a PR, and will then use the jitpack build to verify. Unfortunately we used to have some specific integration tests just to look out for shading issues, but these were quite complex and did not survive the transition to Gradle. Looks like we're going to have to reinstate these, though. |
FYI @dadoonet, relating to #958 As httpcore is a transitive dependency that we don't want to conflict with user's libs, we unfortunately need to: * roll back #959, where we disabled the shading of this module. As is, we're at risk of internal breakage when transitive deps clash. * in turn, stop exposing `HttpHost` in our public API. We should take a general stance of keeping our public APIs free of transitive deps (especially shaded ones) The API method in ElasticsearchContainer will thus change, from: ```java public HttpHost getHost() ``` to: ```java public String getHttpHostAddress() ``` Usage in turn changes from: ```java RestClient client = RestClient.builder(container.getHost()).build(); ``` to the slightly more verbose but equivalent: ```java RestClient client = RestClient.builder(HttpHost.create(container.getHttpHostAddress())).build(); ``` @bsideup, @kiview and I have discussed at length and concluded that this is the only approach that we're comfortable with - despite the fact that this raises an unfortunate breaking change in the API of the Elasticsearch module, which we reluctantly have to do. We are sorry that we did not catch this particular issue at PR stage - we're going to upgrade our static analysis to guard against inadvertent leakage of shaded dependencies. In the longer term we also, obviously, wish to reduce the weight of our dependency chain, both unshaded and shaded, so that this does not happen again. We intend for this change to go out as 1.10.1. I hope this is OK with you @dadoonet - our apologies again for not catching this before release.
Hello.
I've tested elasticsearch container, but test code compile failed by shaded
org.apache.http.HttpHost.just for proof of concepts, i created repository showing this issue.
https://github.com/herblover/testcontainer-elasticsearch-poc
you can reproduce uncommenting
compile files('libs/elasticsearch-jar.jar')inbuild.gradlefile.in my test, testcontainers elasticsearch module should not shade org.apache.http.HttpHost related library. (in case of
./gradlew elasticsearch:jareverything works fine. and./gradlew elasticsearch:shadowgenerated jar file fails.)thank you.
The text was updated successfully, but these errors were encountered: