Gradle Daemon java.lang.LinkageError: org/apache/http/HttpHost

Old Forum
1

We are getting an intermittent LinkageError with the Gradle daemon.

It seems very similar to the following issue: http://issues.gradle.org/browse/GRADLE-2912

This particular stack trace (https://gist.github.com/adrianbk/c4f04be70694af37633e) suggests that gradle cannot resolve the jacoco agent dependency but it happens with different dependencies at different times but always with a VerifyError on the class org/apache/http/HttpHost.

The only way we can get around it is by killing all running daemons and running all commands with the ‘–refresh-dependencies’ flag, this is ok on our CI environment as we can use the org.gradle.daemon arg but on our development environments there is always a Gradle daemon running because of Android Studio - it seems android studio insists on a daemon running in the background. We can kill the daemon process and run --refresh-dependencies but its proving very time consuming.

Project - Android app developed on Android Studio.

  • A unit test module which uses spock 0.7-groovy-2.0 & groovy 2.2.2

  • project has a buildSrc dir with some custom tasks unit tested with spock org.spockframework:spock-core:0.7-groovy-1.8 - Gradle version 1.12 (also occurs on 1.11) - Java version: 1.7 (also occurs on 1.6)

Any idea what may be causing it?

2

This is very strange.

What are the operating systems involved?

3

Ubuntu 14.04 LTS & MAC OSX 10.9.4. The same is happening on both.

4

Given that it’s happening on two separate environments, looks like its project specific.

To isolate this further, can you try some experiments with a hello world type android project on the same machines?

5

I’ll try setup a bare bones app to reproduce it.

Not sure if it’s relevant but we’v got a couple of dependencies which rely on different versions of HttpClient and I’m assuming the default gradle dependency resolution strategy will use the latest version. Also, is it safe to say that any project dependencies do not leak across into Gradle’s internals - org.gradle.api.internal.externalresource.transport.http.HttpClientHelper in this case?

6

I haven’t been able to reproduce it on a bare bones app as it’s intermittent but it’s still happing in the real application. Seems to happen after a couple of recompiles with android studio whereby the daemon gets into a bad state. Also noticed that when it does happen intellij/studio shows 2 gradle daemons in it’s background tasks.

I have opened the following on the android studio forms: https://code.google.com/p/android/issues/detail?id=73283

7

Seems like somehow your http client classes are getting into the daemon’s class space. This obviously shouldn’t happen.

Does anything in your buildSrc depend on HttpClient?

8

buildSrc/build.gradle

dependencies {
  compile gradleApi()
  compile localGroovy()
  //Must use this version of spock to comply with the groovy version gradle uses
  testCompile "org.spockframework:spock-core:0.7-groovy-1.8"
}

Perhaps gradleApi(), it’s got a dependency on httpclient-4.2.2.jar (gradle-core-1.12.jar!/gradle-core-classpath.properties)?

9

Many many projects have this, so it’s unlikely to be the cause.

More likely it’s the fact that you are compiling against http client.