gradleApi() interferes with org.apache.httpcomponents:httpclient:4.5 AllowAllHostnameVerifier

Help/Discuss
1

I am writing a gradle plugin, and it looks like gradleApi() introduces a problem.

Given src/test/groovy/MyTest.groovy:

import org.junit.Test
import org.apache.http.conn.ssl.AllowAllHostnameVerifier
class MyTest {
  @Test
  void myTest() {
    AllowAllHostnameVerifier v = new AllowAllHostnameVerifier()
    println(v.INSTANCE)
  }
}

When build.gradle:

plugins {
  id 'groovy'
}
repositories {
  mavenCentral()
}
dependencies {
  compile gradleApi()
  compile 'org.apache.httpcomponents:httpclient:4.5'
  testCompile "junit:junit:4.12"
}

Then ./gradlew test throws:

MyTest > myTest FAILED
    groovy.lang.MissingPropertyException at MyTest.groovy:7

But when build.gradle does NOT have compile gradleApi():

plugins {
  id 'groovy'
}
repositories {
  mavenCentral()
}
dependencies {
  compile 'org.codehaus.groovy:groovy-all:2.3.10'
  compile 'org.apache.httpcomponents:httpclient:4.5'
  testCompile "junit:junit:4.12"
}

Then there is no problem.

I am writing a gradle plugin, so I must have the compile gradleApi() dependency, so how do I solve this problem?

2

Related to https://issues.gradle.org/browse/GRADLE-1715

3

gradleApi() adds amongst others httpclient-4.2.2.jar to the classpath.
This version does not have the property you use.
But as gradleApi() just adds the files from the gradle installation, they are not listed in the output of “dependencies” task and are also not subject to version conflict resolution.

Anyway, I guess it would be a bad idea to use a newer version of a lib that is shipped with Gradle in a gradle plugin, this might lead to runtime conflicts.
I’d use the shipped version if possible.
But maybe I’m wrong and the plugins have isolated ClassLoaders and just the building is problematic, I’m not sure.

4

Thank you very much. Now I understand. I case someone runs into a similar problem, I find your suggestion of listing the hidden gradleApi() dependencies invaluable:

task libtest << {
  configurations.testCompile.files.each { println it }
}

That’s how we can confirm that httpclient-4.2.2 is pulled into the dependencies tree by gradle (the gradle dependencies command does not show this).

5

In fact, when executing the tasks gradle correctly uses the dependencies of the plugin, this issue only applies to the tests.
Imho, forcing others to use certain versions is not valid option since you cannnot always change that. Moreover, gradleApi handles dependencies internally, so even if you change your libraries in your gradle installation it still forces you to the default versions.