Strange *-tests.jar resolution issue when using mavenLocal()

We’re in the process of upgrading hadoop 2.6.0 to hadoop 2.7.1 for one of our gradle projects. Said project is depended on by another grails project.

We use mavenLocal() for both projects during development. When trying to upgrade hadoop, we’re experiencing a weird issue where once we run the grails project and it resolves all dependencies (including those from the gradle project it is dependent on) into the local maven repo, the gradle project then breaks while it tries to (incorrectly?) resolve a *-tests.jar of one of our dependencies out of mavenLocal (specifically zookeeper:3.4.6). This despite the fact that both versions of hadoop use the same version of zookeeper. Yet we never experienced this issue with hadoop 2.6.0.

Prior to resolving this via grails and hence caching the artifact in maven locally, the gradle project works fine, resolving the dependency into it’s own local artifact cache. But as soon as you run grails and get the zookeeper dependency into the local maven repo, the use of mavenLocal() causes the gradle project to fail.

I’ve created two bare projects - one gradle, one grails, that reproduces this at Simply doing a grailsw compile in the grails project and then gradlew dependencies in the gradle project should suffice to reproduce this. Both projects have matching wrappers with what we are using internally. You’ll see that if you switch the dependencies in the gradle project to the 2.6.0 ones that are commented out, everything works fine.

What am I missing?

A bit more info. Both Hadoop 2.6.0 and 2.7.1 have this in their hadoop-common POM:


Yet again, with 2.7.1, resolving compile time dependencies results in the following if zookeeper exists in my local maven repository:

> Could not resolve all dependencies for configuration ':compile'.
    > Could not find zookeeper-tests.jar (org.apache.zookeeper:zookeeper:3.4.6).
      Searched in the following locations:

FWIW, what I’m experiencing seems to essentially be the same as this:

The weird thing is how it does/doesnt work depending on the version of the parent dependency I’m trying to resolve, and I can’t find what differs between the two versions that would now cause this.

For future reference, the solution was to exclude the module that had the related *-tests.jar and explicitly include it but with the @jar extension, which apparently causes resolution to exclude the tests jars.