I think I’ve figured this out (finally). The HBase dependency appears to bring in a Hadoop transitive dependency. And Gradle apparently changed the classspath ordering in Gradle 2. Adding this exclusion to the HBase dependency does the trick.
exclude(group: “org.apache.hadoop”)
I assumed the order should be alphabetical (in which case you’d think hadoop would win over hbase), but I suppose there’s no specification of the “correct” classpath order. If there is, or at least documentation of what changed in Gradle 2, I’d appreciate a link.
With 2.0, gradle started recognizing default pom profiles - see 2.0 release notes . Hbase-client has a pom whose default profile pulls in org.apache.hadoop:hadoop-core which has the additional implementation of LocalJobRunner.
Point is, this issue has been there all along, but Gradle didn’t honor the default pom profile before 2.0, so it was never an issue.
Ah, I see. I appreciate your explanation. What about the dependency tree the dependencies command gives? Shouldn’t it show the hadoop-core dependency it tries to pull in from the default profile?
Hadoop-core does show up for me if I run it with 2.1 (I assume it also shows with 2.0, but I didn’t try). It’s only not there if I use a 1.x version of gradle.
My output doesn’t have hadoop-core in it (I tried with both 2.0 and 2.1). Could there be some global configuration I have that is altering Gradle’s behavior on my machine? I’ve linked my output in my first comment.
You know, I think I misinterpreted the tree representation. I got a tree that looked kinda like this for most scopes
Argh…Sorry, I’m not awake yet this morning. It didn’t show up in my tree because I forgot to comment back out my fix. I would still like to hear what the backslashes mean though.