are there gradlew or gradle caches on linux?

Question

Are there caches or other environment files that can cause gradle to throw this error?

    Exception in thread "main" java.lang.NullPointerException
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMainStarter.java:34)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:58)

I'm building a Jenkins CI server for building android apps. The Jenkins master passes the job off to an AWS linux slave, where it

1. Wipes the previous workspace
2. Downloads the github repo
3. moves into the project folder
4. ./gradlew clean build

Then it throws the exception above. Other repos using ./gradlew build on this machine. This repo built prior to: adding additional disk space to the machine and downloading more android SDKs, neither of which should affect gradlew. Attempting to build the exact repo that built, with the same configuration that built still throws the same exception.

I added echoes to the gradlew file to see where the problem happens, and all of them sound prior to the final line: exec "$JAVACMD" "${JVM_OPTS[@]}" -classpath "$CLASSPATH" org.gradle.wrapper.GradleWrapperMain "$@"

What do I need to do to make this build?

Answer 1

Something must be messing with your gradle wrapper setup. I would highly recommend the Jenkins Gradle Plugin. It has made my gradle builds trivial. You can specify any path to the build.gradle if it is not in the root workspace.

Answer 2

This took some hunting, but here is the solution that I found. Jenkins (by default) does not have access to the $PATH or any default applications (so that the computer can run Ruby 2.2 and your CI jobs can run Ruby 1.0 for example) Iff you look in the script that is causing the error, it's because it calls a script which calls a script ect, until at some level down (I want to say 7) it calls the diff function. because this dependency was written assuming that your UNIX box knows the baked in applications. Because the Jenkins user calling this function doesn't know that this binary exists, and the way the entire script is written it throws the exception above. Hope this helps