When I use the Gradle tooling API in my custom plugin, I get a lot of noise at the console, e.g.:
Creating ClassLoader af47d36a-0f9f-40d2-8bc3-b32738455061 from system and [org.gradle.internal.classloader.FilteringClassLoader@5aa153ee].
Creating ClassLoader 0088fcb2-a08b-48a1-92f9-94d18f846340 from org.gradle.internal.classloader.MutableURLClassLoader$Spec@62f1c342 and [org.gradle.internal.classloader.FilteringClassLoader@5aa153ee].
(and half a dozen similar lines), and
Tooling API is using target Gradle version: 2.0.
Connected to the daemon. Dispatching Build{id=b0b916a3-d386-4088-8d00-d321216263ca.1,currentDir=/home/dmoles/Projects/makeproject-new} request.
How can I suppress this? I tried configuring SLF4J to use Log4J in my plugin’s ‘build.gradle’ (I have no idea what it uses by default) and setting an ERROR-level appender for ‘org.gradle’ in my ‘log4j.xml’, but that appears to do nothing.
I then tried adding a Logback configuration file to my plugin’s ‘src/main/resources’ (see gist), rebuilt the plugin, refreshed dependencies in the project that uses the plugin, and invoked it again, but I still get all the tooling DEBUG output. Setting the root level to ERROR also has no effect (not even on log output from my own plugin code, so I’m not sure what’s going on there).
I also tried programmatically reconfiguring the log level but ran into classloader issues:
The following classes appear as argument class and as parameter class, but are defined by different class loader:
ch.qos.logback.classic.Level (defined by ‘java.net.URLClassLoader@56464aa5’ and ‘org.gradle.internal.classloader.MutableURLClassLoader@7e41986c’)