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 org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:90) at org.elasticsearch.test.ESTestCase.<clinit>(ESTestCase.java:138) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:585) Caused by: java.lang.IllegalStateException: jar hell! class: io.netty.util.HashingStrategy$1 jar1: F:\maven\repo\io\netty\netty-common\4.1.5.Final\netty-common-4.1.5.Final.jar jar2: F:\maven\repo\io\netty\netty-all\4.1.5.Final\netty-all-4.1.5.Final.jar at org.elasticsearch.bootstrap.JarHell.checkClass(JarHell.java:291) at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:187) at org.elasticsearch.bootstrap.JarHell.checkJarHell(JarHell.java:88) at org.elasticsearch.bootstrap.BootstrapForTesting.<clinit>(BootstrapForTesting.java:88) ... 4 more
References to jar hell: