Guava in Gradle's classpath

Help/Discuss
1

Hello!

I am working on a plugin that uses Guava via transitive dependencies. Unfortunately, I have found that Gradle already includes Guava (v. 17.0): https://github.com/gradle-clojure/gradle-clojure/issues/28#issuecomment-344698308.

I noticed that Gradle also includes re-packaged Guava under org.gradle.internal.impldep.com.google.common.base package but as stated by the exception from the linked issue, the original Guava classes are used by gradle-base-services module.

What is the policy for Guava dependency in Gradle distribution? Should the modules use the re-packaged version so the plugins can add their own version? If not, is there any isolation mechanism that could allow a plugin to use a different Guava version?

Best regards,
Piotr

2

You can use any version of Guava you want, Gradle does not leak its own version into your plugin.

3

Thank you for your reply.

As you can see in the linked issue, when I don’t specify Guava dependency in my plugin, version 17 is added by Gradle to satisfy gradle-base-services module requirements and is loaded (in my example) from the following path:

~/.gradle/wrapper/dists/gradle-4.3-rc-1-bin/4dpv3r3e5mwtficz0bbnrpkn4/gradle-4.3-rc-1/lib/guava-jdk5-17.0.jar

and this path is part of the Gradle distribution. guava-jdk5-17.0.jar archive contains Guava classes in their original packages - they are not repackaged under internal Gradle package.

Am I misunderstanding something here?

4

Guava is not part of Gradle’s API, so it will not be exposed to your plugin. We have filtering classloaders that make sure that your plugin cannot see it. Can you provide a reproducible example where you had this problem?

5

I don’t have minimal example but I will try to prepare one this week when I have more time.

We are using WorkerExecutor with isolation mode set to PROCESS. I guess it might be the issue of classpath of the worker, not the main Gradle process.

6

FWIW I just built a project which doesn’t have any guava dependency and i can see guava being downloaded

e[4Ae[1m<-------------> 0% INITIALIZING [22s]e[me[37De[1Be[1m> root project > Resolve dependencies :example-transform:classpathe[me[66De[1B> IDLEe[6De[1Be[1m> plexus-component-annotations-1.7.1.pome[me[40De[1Be[4A
Download https://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-annotations/1.7.1/plexus-component-annotations-1.7.1.pome[0K 
Download https://repo1.maven.org/maven2/org/apache/maven/maven-artifact/3.5.2/maven-artifact-3.5.2.pome[0K 
Download https://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.7.1/plexus-containers-1.7.1.pome[0K 
Download https://repo1.maven.org/maven2/org/apache/maven/maven-builder-support/3.5.2/maven-builder-support-3.5.2.pome[0K 
Download https://repo1.maven.org/maven2/com/google/guava/guava/20.0/guava-20.0.pom Download https://repo1.maven.org/maven2/com/google/guava/guava-parent/20.0/guava-parent-20.0.pom

Build log here source here

7

Hello @Lance,

Guava dependency is not downloaded as part of dependencies, it is included on classpath from Gradle wrapper downloaded distribution’s lib directory.

8

That’s a transitive dependency of the plugin-publish plugin and it’s in the buildscript.classpath. It’s expected that that would be visible until we have some isolation between external plugins.

But Piotrek was saying that he gets the Guava library from the Gradle distribution, which should never happen.

@Gary_Hale do we have some tests for worker executors not leaking Guava and other dependencies?

9

Ah… yeah… I always forget that’s an external plugin. It feels like core behaviour

10

Stefan, I created a minimal reproducible example of Guava being visible in a worker.

I think this is causing a number of problems in our Clojure plugin.

11

Thanks Andrew, that’s super helpful. I can reproduce the issue and opened https://github.com/gradle/gradle/issues/3698 for this.

1 Like