I have been fighting with Gradle for more than a few hours trying to build a Grails app using the Gradle Grails Plugin. When running the Grails test task from Gradle (i.e.
$gradle test), I got the error “Could not find or load main class org.grails.launcher.Main.
I’ve seen plenty of online postings and screen casts showing this plugin working, but I just couldn’t figure out the incantation needed to get it to work. Man, how I hate getting errors right out of the gate!
To isolate the issues as much as possible, I did a Grails create-app to create an empty project. I then created a build script copied from the the plugin docs, changing the version numbers to match my environment, and updating the dependencies section. My Grails and Gradle versions are 2.4.4 and 2.2.1 respectively. The plugin is declared with:
NOTE: When redeclaring the BuildConfig dependencies in the Gradle build file, be sure to include the group identifier. For instance, in BuildConfig,
compile ":asset-pipeline:1.9.9" becomes
compile "org.grails.plugins:asset-pipeline:1.9.9" in the Gradle build file. Ick, right? Fortunately, we only have to deal with this kind of thing until Grails 3.0 when Grails switches to Gradle as its build system.
(If interested, you can find the complete build file in a GIST.)
Thinking it was my issue caused by some version mismatch between Gradle/Grails/Gradle-Grails-plugin, I went down the rabbit hole of changing around the various versions of Grails, Gradle, and the plugin. (Don’t believe everything you read on the Internet. 🙂 )
On closer inspection of the output from running
gradle --info test, I learned the command being issued is:
C:\swdev\Tools\Java\jdk1.7.0_51\bin\java.exe -Dfile.encoding=windows-1252 -Duser.country=US -Duser.language=en -Duser.variant -cp C:\Users\Jack%20Frosch\.gradle\caches\modules-2\files-2.1\org.grails\grails-launcher\1.1\21830b348c731e5f2ae24a5193412bfda73222b9\grails
-launcher-1.1.jar org.grails.launcher.Main D:\temp\testGradleGrailsPlugin\build\tmp\test\launch.context
Exasperated, I cracked open the Grails Launcher JAR specified in the classpath of the command being launched by the plugin. My theory was the version of the JAR in my classpath had the Main class in a different package than the plugin expected. Alas, the Main class is exactly where the plugin expected it to be.
Then it hit me – the classpath includes an encoded space (%20) in my name. Ugh. That kind of escaping may be useful for browsers, but I hypothesized it likely wouldn’t be helpful to the Java executable being launched from the Windows command line.
To test my hypothesis, I copied the command to a text editor, put the classpath string in quotes, and changed the %20 to a space. Copying the modified command back to the command line, I demonstrated to myself the encoding of the space completely fouled Java’s ability to interpret the path resulting in the error.
After a little more Googling, I found a Stackoverflow posting about setting the GRADLE_USER_HOME environment variable to a path containing no spaces. By changing the GRADLE_USER_HOME to a short directory without spaces in the path, I was able to sidestep the issue altogether.
I hope this saves you a few hairs during your next hair pulling coding experience.