Custom Tasks
You can define custom tasks which you expect to execute relatively often. That is, tasks defined here can be selected in the project's context menu (under "Custom Tasks").
In each of the edit boxes, you can use the following variable (it is possible that new ones will be added in the future):
- ${project}: This will be replaced by the fully qualified name of the project on which you execute a task (except on the root project where it is an empty string). This is advantageous when you want to execute task of project and not the tasks of the subproject (for example: you write ${project}:clean as a task).
- ${platform-dir}: The path to the JDK specified in the project properties for the "Target platform".
- ${env.XXX}: The value of the given XXX environment variable. If the variable does not exist, the variable will be treated as a custom task variable. (since version 1.3.6)
Note: You may also use custom variables (since version 1.2.4).
To add a new custom task simply click "Add New" and enter the display name of the task. This is the name which will be displayed in the context menu and may contain any character. Once you have added a task you can go ahead adjusting it.
The most important is to set the tasks to be executed. You can specify multiple tasks (and rules) here which are to be executed in the order they are specified. The tasks are separated by spaces (trailing and leading spaces are ignored).
You might also want to specify arguments for the Gradle command to be executed. These are the arguments which you would pass to "gradle" in the command line other than tasks. Arguments always start with a dash ("-").
Since the tasks run in a separate Java process, you can specify arguments for the JVM in which the tasks are to be executed. You can specify any argument valid for the JVM but I recommend to set memory constraints (e.g.: "-Xmx") in the global settings instead of here, so you only need to specify it once.
Notice that you can specify if a task is "non-blocking task". The reason to make distinctions about blocking and non-blocking tasks is purely for performance reasons. The rule about them is that if a non-blocking task is currently being executed (you can consider loading a project as a non-blocking task), other tasks will be queued and wait for this task to complete (even blocking tasks). If a currently running task is a blocking task, then subsequent task executions will simply execute concurrently with this task. To not execute tasks concurrently is important to avoid needlessly spawning new Gradle daemon processes (these processes carry out all the work for Gradle and are anything but lightweight processes) because these processes will remain for 3 hours (by default) with you if you don't kill them manually.
If you check "Tasks must exist", the plugin will check if the project on which you might attempt to execute the task actually contains a task named as the tasks listed in the definition. If the plugin cannot find the task, it will not show your custom task in the "Custom Task" context menu. Notice that Gradle allows to define rules (cleanTest for example) which look similar to tasks when being executed but are not really tasks and therefore the plugin won't (and cannot) detect them. Also you need to reload a project to refresh the knowledge of the plugin of the list of tasks a project defines. Knowing this, it is up to you to check this checkbox or not.