Using Guava 12.0.1 with Custom Plugin


(Christopher Molozian) #1

I’m developing a Gradle plugin which acts as a driver for the Google Closure Stylesheets compiler. I’ve run into some problems running the plugin because of this error message:

Caused by: java.lang.NoSuchMethodError: com.google.common.collect.Queues.newArrayDeque()Ljava/util/ArrayDeque;

The Closure Stylesheets compiler depends on Guava 12.0.0 but according to this line in (gradle/dependencies.gradle):

guava: 'com.google.guava:guava:11.0.2@jar',

Gradle itself depends on an earlier version of the library… I can confirm that ‘Queues.newArrayDeque()’ was not added to Guava until the 12.0 release: http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Queues.html#newArrayDeque()

Does Gradle share it’s dependencies with plugins?

Is it possible to force the plugin to use Guava 12.0+ ?


(Luke Daley) #2

Hi Chris,

The classloaders are supposed to be isolated. Any chance that you could put together a sample that I can use to explore this problem?

Also, have you checked as to whether the https://github.com/eriwen/gradle-js-plugin does what you need?


(Christopher Molozian) #3

Hey Luke,

The code I’ve put together so far for the custom plugin is fairly minimal so I’ve simply open-sourced the work. I was planning to open-source it anyway after everything was working.

You can find the project here:

https://github.com/PieceOf8/gradle-closure-plugin

The unit test code that’s failing is rather ugly at the moment, it’s here:

https://github.com/PieceOf8/gradle-closure-plugin/blob/master/src/test/java/com/pieceof8/gradle/closure/CompileGssTaskTest.java

Btw, I really really really wish that there was a way to run a plugin in a build lifecycle with Gradle without putting the plugin in a “buildSrc” folder. If I put it in the buildSrc folder then I get errors when using the Gradle Signing plugin because the buildSrc project doesn’t have a project name…

The plugin that I’m developing is to power the Google Closure Stylesheets compiler (http://code.google.com/p/closure-stylesheets/) not the Google Closure Compiler (for Javascript).

Thanks for your help on this.


(Luke Daley) #4

You can find the project here

Thanks. We’ll take a look and let you know.

Btw, I really really really wish that there was a way to run a plugin in a build lifecycle with Gradle without putting the plugin in a “buildSrc” folder

This is pain that we know about. We are working towards removing the need for this special handling and making it possible to use any project as a build resource for another project. However, this is very challenging and is going to take a while to achieve.

There are other things in the pipeline such as dynamic project composites, but that too will take some time.

If I put it in the buildSrc folder then I get errors when using the Gradle Signing plugin because the buildSrc project doesn’t have a project name…

I was unaware of this problem. Would you mind opening a separate topic for that. That’s something we should be able to fix.

The plugin that I’m developing is to power the Google Closure Stylesheets compiler

If you’re up for it, it might be worth touch base with the author of https://github.com/eriwen/gradle-css-plugin to consolidate work.


(Luke Daley) #5

I just re-read your post.

Classloader isolation is in effect at runtime (i.e. when actually using your plugin), but test time is a bit different.

You’re hitting GRADLE-1715.


(Christopher Molozian) #6

I guess I should have checked the Gradle Issue Tracker, I’d just assumed that I’d missed something about unit testing for plugin development.

I’ll construct a minimal Gradle project that demonstrates the error with the Gradle Signing Plugin.

I’ll speak to Eric about possible collaboration on a plugin that can manage CSS preprocessors to transform them to CSS. My current focus on the gradle-closure-plugin is to create a plugin capable of working with the entire Google Closure Toolchain. I’m not sure our goals will align on this plugin but we’ll see.

Thanks for the quick replies.


(Christopher Molozian) #7

Hi Luke,

I realized that instead of creating an example project that demonstrates the problems with the Signing plugin and a plugin in the “buildSrc” folder I thought you could use a real world plugin project.

This version of my Gradle Snapshot plugin was formatted that way to make it easy to test the plugin in Gradle’s build lifecycle during development.

https://github.com/PieceOf8/gradle-snapshot-plugin/tree/3e298df1a96d4aba16a80c1d1f5ba0af8687c44f

You can see with subsequent commits that I had to change it to be able to deploy the plugin to Maven Central.

Basically: 1) git clone git://github.com/PieceOf8/gradle-snapshot-plugin.git 2) cd gradle-snapshot-plugin 3) git checkout 3e298df1a96d4aba16a80c1d1f5ba0af8687c44f 4) cd buildSrc 5) gradle uploadArchives

Caused by: java.lang.IllegalArgumentException: Neither path nor baseDir may be null or empty string. path='' basedir='/Users/chris/Desktop/gradle-snapshot-plugin/buildSrc'
 at org.gradle.api.internal.file.BaseDirFileResolver.doResolve(BaseDirFileResolver.java:68)
 at org.gradle.api.internal.file.AbstractFileResolver.resolve(AbstractFileResolver.java:57)
 at org.gradle.api.internal.file.AbstractFileResolver.resolve(AbstractFileResolver.java:53)
 at org.gradle.api.internal.file.DefaultFileOperations.file(DefaultFileOperations.java:63)
 at org.gradle.api.internal.project.AbstractProject.file(AbstractProject.java:651)
 at org.gradle.api.Project$file.call(Unknown Source)

Let me know if you need me to put together a sample project.