I also get this problem. In my case, it’s not related to a version upgrade - it fails with both 1.2 and 1.5. Here is a tiny project demonstrating the problem - try running ‘gradle test’:
Essentially, this is a project with a compile dependency on the JavaEE API jar from Sun/Oracle, and a test runtime dependency on the JavaEE specs jars from JBoss. This is a quite common arrangement: the official API jar contains deliberately broken class files that can be used to compile against, but cannot be used at runtime, eg in unit tests, so an alternative, non-broken, implementation of the API is used to run the tests.
The crucial thing here is that both dependencies define the same set of classes (or at least, an overlapping set). We require the dependency defined in testRuntime to override the one defined in compile. It seems that this does not happen.
Note that if you remove the compile dependency from this little project, the tests pass, because now they link against the testRuntime dependency. Obviously, this is not practical in a real project, where the compile dependency is needed to compile code!
It would be possible to use the testRuntime dependency as a compile dependency as well, but this is not desirable, because it would tie the built artifact to a particular non-official implementation of the API. It could be done as a providedCompile dependency to avoid this, but this only works for WAR projects, and loses the dependency from the artifact altogether, which is also bad.
The fix for this issue, i believe, is to ensure that jars which are testRuntime dependencies (direct or transitive) should take precedence over those which are compile dependencies.
I’m happy to raise a bug for this, if that would be more useful.