If you followed the installation instructions, and aren’t able to execute your Gradle build, here are some tips that may help.
If you installed Gradle outside of just invoking the Gradle Wrapper, you can check your Gradle installation by running
gradle --version in a terminal.
You should see something like this:
❯ gradle --version ----------------------------------------------------------- Gradle 4.6 ------------------------------------------------------------ Build time: 2018-02-21 15:28:42 UTC Revision: 819e0059da49f469d3e9b2896dc4e72537c4847d Groovy: 2.4.12 Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017 JVM: 1.8.0_151 (Oracle Corporation 25.151-b12) OS: Mac OS X 10.13.3 x86_64
If not, here are some things you might see instead.
If you get "command not found: gradle", you need to ensure that Gradle is properly added to your
If you get something like:
ERROR: JAVA_HOME is set to an invalid directory Please set the JAVA_HOME variable in your environment to match the location of your Java installation.
If you get "permission denied", that means that Gradle likely exists in the correct place, but it is not executable.
You can fix this using
chmod +x path/to/executable on *nix-based systems.
gradle --version works, but all of your builds fail with the same error, it is possible there is a problem with one of your Gradle build configuration scripts.
You can verify the problem is with Gradle scripts by running
gradle help which executes configuration scripts, but no Gradle tasks. If the error persists, build configuration is problematic.
If not, then the problem exists within the execution of one or more of the requested tasks (Gradle executes configuration scripts first, and then executes build steps).
Common dependency resolution issues such as resolving version conflicts are covered in Troubleshooting Dependency Resolution.
You can see a dependency tree and see which resolved dependency versions differed from what was requested by clicking the Dependencies view and using the search functionality, specifying the resolution reason.
The actual build scan with filtering criteria is available for exploration.
For build performance issues (including “slow sync time”), see the guide to Improving the Performance of Gradle Builds.
You can set breakpoints and debug buildSrc and standalone plugins in your Gradle build itself by setting the
org.gradle.debug property to “true” and then attaching a remote debugger to port 5005.
❯ gradle help -Dorg.gradle.debug=true --no-daemon
In addition, if you’ve adopted the Kotlin DSL, you can also debug build scripts themselves.
You must either stop running Gradle Daemons or run with
You can also replace much of Gradle’s logging with your own by registering various event listeners. One example of a custom event logger is explained in the logging documentation. You can also control logging from external tools, making them more verbose in order to debug their execution.
Additional logs from the Gradle Daemon can be found under
--info logs explain why a task was executed, though build scans do this in a searchable, visual way by going to the Timeline view and clicking on the task you want to inspect.
You can learn what the task outcomes mean from this listing.
NOTE: This only works for Gradle projects linked to IntelliJ.
From the main menu, go to
Tool Windows >
Gradle. Then click on the Refresh icon.
If you’re using Buildship for the Eclipse IDE, you can re-synchronize your Gradle build by opening the "Gradle Tasks" view and clicking the "Refresh" icon, or by executing the
Refresh Gradle Project command from the context menu while editing a Gradle script.