Plugins block does not handle classpath correctly under certain circumstances

gradle-3503

(Schalk Cronjé) #1

@eljobe, @st_oehme,

As mentioned to you at GradleSummit, here is the sample project that does not work correctly with the plugins {} closure.

https://github.com/ysb33r/SampleProjects/tree/GradleNewModel/PluginsBlockDoesNotHandleClasspath

old-style.gradle is the one that works, and new-style.gradle, which contains the plugins block, fails. The error that is reported is directly related to the plugin not seeing the appropriate JARs on the classpath when it is applied.


(Pepper Lebeck-Jobe) #2

I can confirm that I can reproduce this problem with Gradle 3.0-M2.

We are pretty busy right now, but we will be looking into this.


(Schalk Cronjé) #3

No problem. There is a workaround.


(Stefan Oehme) #4

Can you tell us a bit more about how the plugin decides which URI schemes to activate? I debugged and can see that the http-client jar is on the classpath and the classloader of your plugin can see the HttpClient class. So I’m a little lost as to why it would not work.


(Schalk Cronjé) #5

When the plugin is applied the VFS object is initialised at

which in turn instantiates it via

Drilling down into the Groovy VFS library the key to loading lies within the specification for ZIP

and for http

Evautally the loading occurs by checking first whether the dependsOnClasses are on the classpath

and then by whether the className itself is on the classpath.

If any of the required classes are not on the classpath at the given initialisation then the specific scheme providers are not loaded.


(Schalk Cronjé) #6

VFS allows for double-barrel scheme names i.e. zip:http://foo/path/file.zip which allows for file.zip to be downloaded to a temporary file store, and then be interpreted as a ZIP in a way that is transparent to the used


(Stefan Oehme) #7

I think I found the problem: The StandardFileSystemManager uses the current Thread’s context classloader. That classloader is different for the logic running inside the plugins block. If the plugin used getClass().getClassLoader() instead, it would work.

I’m going to bring this up for internal discussion, as other plugin authors might trip over this slight change in the environment that the plugin runs in. Thanks for taking the time to walk me through your plugin :slight_smile:


(Schalk Cronjé) #8

Wow, that makes sense.

I definitely would be interested in what the outcome of that discussion would be. If need be I can craft up a version of the plugin on a branch that uses a different classloader to test any ideas forthcoming.


(Stefan Oehme) #9

I’ve raised GRADLE-3503, which we will fix for 3.0.