Elasticsearch 5 forces me to use the ESIntegTestCase instead of starting my own Node for my integration tests from Java because NodeBuilder is not available anymore. So I try to do things the right way using:
My product uses a large number of dependencies that are also used by Elasticsearch. For example apache.commons codec and logging and Netty.io. Due to the strict nature of ESIntegTestCase it is required to use a clean classpath in the integration tests. There is the jar hell checker to check this.
I understand the purpose of this check and I have read multiple issues and discussions about it. But it makes writing an integration test really impossible.
Example: I depend on netty-all-final4.1.5.jar and Elasticsearch depends on the same Netty jars, but not on the final distribution but on the separate jars. To get the integration test working I must either rewrite my code to depend on the separate netty.io jars (netty-buffer, netty-common, netty-codec, etcetera) and use the same approach as Elasticsearch uses. Or I have to exclude a number of dependencies manually in my integration test dependencies.
And next time Elasticsearch upgrades and uses some other approach I have to redo this error prone work again.
Is there a trick to circumvent the jar hell checker? I'm not writing ES integration tests, I'm writing integration tests for my own product, which has to talk against ES.
java.lang.RuntimeException: found jar hell in test classpath
at java.lang.Class.forName0(Native Method)
Caused by: java.lang.IllegalStateException: jar hell!
... 4 more
We have the same issue as you. We were using the NodeBuilder to run our integration tests against our Search API which is a Spring Boot application. Since the upgrade to Elasticsearch 5 we can no longer use this method.
I'm going to switch to using the ESIntegTestCase instead, but did you find a clean way to resolve the Jar Hell issues?