Upgrading Gradle versions gives "loader constraint violation" errors

(Douglas Bullard) #1

We’ve been having trouble when upgrading Gradle versions. We get errors like the following when going from 1.6 to 1.7:

gradlew test
  FAILURE: Build failed with an exception.
  * What went wrong:
Could not resolve all dependencies for configuration ':testCompile'.
> Could not resolve org.testng:testng:6.8.5.
  Required by:
      com.nike.das:das-webapp:1.4
   > loader constraint violation: loader (instance of org/gradle/util/MutableURLClassLoader) previously initiated loading for a different type with name "org/apache/http/HttpHost"
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
> Could not resolve org.springframework:spring-test:3.1.0.RELEASE.
  Required by:
      com.nike.das:das-webapp:1.4
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost
   > org/apache/http/HttpHost

This will happen until you run Gradle with the --refresh-dependencies flag. It’s particularly annoying on our CI boxes, as we have to leave --refresh-dependencies in until all agents have been dealt with, and that makes the builds much slower.

We’re running Gradle on OS X, CentOS, and Windows - all with the same results. It’s happened on almost every Gradle version upgrade, we just haven’t filed a bug until now.

Is there a better way to deal with this?

Thanks.

(Peter Niederwieser) #2

I don’t recall seeing this error before. Do you always run a clean build after switching Gradle version (it’s required)? Do you use a custom Gradle distribution? Is it always the same class (‘org/apache/http/HttpHost’)? Does this only occur when using the Gradle daemon? Can you post the full stack trace (’–full-stacktrace’) as a GitHub Gist?

(Douglas Bullard) #3

Tried it with “clean” added, same result. Full stack trakes with --full-stacktrace is at [https://gist.github.com/anonymous/6453749]((https://gist.github.com/anonymous/6453749).

We’re using the straight Gradle distribution - no customizations. And it’s always the same class. Running with the daemon or without produces the same results.

(Peter Niederwieser) #4

Can you double-check that you are running Gradle with a clean JRE installation that doesn’t, say, have libraries in ‘lib/ext’?

(Douglas Bullard) #5

They’re clean - agents have clean, unmodified JDK installations. I can try fresh JDK installation (1.7.0_21 currently, can update to _25).

We never add stuff to the JDK, and since we’ve seen this on OS X, Windows, and CentOS it’s not likely a corporate update could affect that (corporate loves to modify stuff on our boxes, but the CentOS boxes aren’t affected)

(Douglas Bullard) #6

I confirmed this by upgrading the boxes to 1.7.0_25. Still seeing this issue.

Interestingly enough, not all configurations produce this error - “gradlew test” doesn’t, but “gradlew functionalTest” does. Different libraries required, I suppose.

(Peter Niederwieser) #7

Can you verify where the ‘org/apache/http/HttpHost’ class gets loaded from, perhaps by setting ‘export GRADLE_OPTS=-XX:+TraceClassLoading’?

(Douglas Bullard) #8

Here’s the gist: https://gist.github.com/anonymous/6498194

Interesting… I don’t see “HttpHost” anywhere in the class loading, just in the error itself.

A thought - do we need to run the “wrapper” task with every upgrade? We tend not to, as just changing the location of the Gradle repository in the gradle-wrapper.properties does the trick. In any case, I’ve tried that, and it doesn’t help. And I do kill the daemon between runs, just in case.

(Douglas Bullard) #9

Peter, we’re getting this AGAIN when upgrading from 1.7 to Gradle 1.8…

I spoke with Hans at JavaOne last week, he’d really like to get to the bottom of this. He suggested perhaps a Skype session or something to help figure it out.

(Attila Kelemen) #10

I’m also getting this error when moving from the old Tooling API to the new one in 1.8. I’m not sure if the exception is the same issue but it is a loader constraint violation as well (https://gist.github.com/kelemen/6600845). I already told this to Adam but we couldn’t yet come up with any solution or workaround. Given that others have this error as well, the issue might not caused by the new Tooling API as I believed (it could be a coincidence).

(Peter Niederwieser) #11

Raised GRADLE-2912.