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?

Tried it with "clean" added, same result. Full stack trakes with --full-stacktrace is at [[1]https://gist.github.com/anonymous/645....

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.
----------------------------------------------------------------------------------------
[1] https://gist.github.com/anonymous/6453749]((https://gist.github.com/anonymous/6453749)

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

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)

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.

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

Here's the gist: [[1]https://gist.github.com/anonymous/649...

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.
----------------------------------------------------------------------------------------
[1] https://gist.github.com/anonymous/6498194](https://gist.github.com/anonymous/6498194)

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.

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 ([1]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).
----------------------------------------------------------------------------------------
[1] https://gist.github.com/kelemen/6600845

Investigating the problem with the help of NetBeans developers, the issue seems to be that Gradle adds the tooling.jar to the class path of the application (`sun.misc.Launcher$ExtClassLoader`, I believe). The problematic class is the following: https://github.com/gradle/gradle/blob/RB_1.8/subprojects/core/src/main/groovy/org/gradle/initialization/DefaultClassLoaderRegistry.java.

I don't know where exactly tools.jar is used in Gradle, so I will now get back to Adam as he seems to be the only one editing that file.

This issue is critical: That is, affects users using previous version of the Tooling API as well. For NetBeans this means, that anyone switching to Gradle 1.8 will find NetBeans broken (debugging not working and not just for Gradle projects). Other tools (IDEs, CIs) using the Tooling API might be affected as well, I haven't checked.

This means, that switching to Gradle 1.8 is risky to be recommended until the Tooling API is fixed. The best case is that "only" NetBeans is unusable for Gradle 1.8.

It is fixed in the nightly build "1.10-20131011231056+0000" for NetBeans. However, it is still not possible to connect to a Gradle 1.8 daemon.

@Douglas: Do you still have the issue using the nightly? Although, given the name of the conflicting class, yours might be a different issue.

Nope, as of build 1.10-20131023220031+0000 I still get it when switching versions:
gradle test
Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true

========================================================================================================
Welcome to Gradle version 1.10-20131023220031+0000
Java version is: 1.7.0_40 (Oracle Corporation 24.0-b56)
========================================================================================================

The Test.testReportDir property has been deprecated and is scheduled to be removed in Gradle 2.0. Please use the Test.getReports().getHtml().getDestination() property instead.
Creating properties on demand (a.k.a. dynamic properties) has been deprecated and is scheduled to be removed in Gradle 2.0. Please read http://gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html for information on the replacement for dynamic properties.
Deprecated dynamic property: "testReportDir" on "task ':runAutomation'", value: "/Users/Shared/Developm...".
:compileJava UP-TO-DATE
:compileGroovy

FAILURE: Build failed with an exception.

• What went wrong:
  Could not resolve all dependencies for configuration ':compile'.
  > Could not resolve net.sourceforge.nekohtml:nekohtml:1.9.15.
  Required by:
  com.nike.das:das-webapp:1.4 > org.seleniumhq.selenium:selenium-java:2.20.0 > org.seleniumhq.selenium:selenium-htmlunit-driver:2.20.0 > net.sourceforge.htmlunit:htmlunit:2.9
  > 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

Upgrading to 1.10 at work, still having this issue.

What's strange is that I don't get this at all from home - and I'm using a pretty similar stack (OS X, JDK version, etc).

Getting this yet again when upgrading from 2.3 to 2.4...

BUT, I found a smoking gun...

If I run the following script when this occurs:

killall java
rm -rf /nikeDev/gradleHome/caches//modules-2/metadata-2.14/descriptors/org.apache.httpcomponents
rm -rf /nikeDev/gradleHome/caches//modules-2/files-2.1/org.apache.httpcomponents

This fixes it every time. What appears to be happening is that Gradle depends on HttpComponents 4.2.2 - and our application uses HttpComponents 4.3.3 or so. Running Gradle without 4.3.3 in the cache works ok - but if you switch versions of gradle (or upgrade JDK), it'll apparentliy bring in other versions of HttpComponents into Gradle's path somehow - the issue arises when a version of HttpClient isn't the same as HttpCore.

I think running the script above works because when the daemon loads there are no other versions of HttpComponents in existance, so it gets the right version - then it loads the application jars, and the daemon is already loaded, so that's OK. Change versions of Gradle or Java, it tries to reload the daemon with the other versions all in the same path - you get that error at runtime.

I'm hoping this helps. This is a significant issue with us, and is giving Gradle a black eye (our CI machines are a pain to clear out when we upgrade)

You have to kill the daemons, as they a

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Keep this bug open in GitHub, we still see this with 3.1

@Douglas Could you please open an issue on GitHub and provide a sample project that reproduces the issue? I am not quite sure how to run into the issue.

I have no way to reproduce the issue on my machine. Please open an issue on GitHub if you are still running into the problem by producing a reproducible example.