If I run ./gradlew clean
or ./gradlew tasks --all
, it is always running my compile task(which I overwrote in the gradle build script like the below)
task eclipse(overwrite: true) {
exec { commandLine = ["./play1.3.x/play", "eclipsify"] }
}
task compileJava(overwrite: true) {
exec { commandLine = ["./play1.3.x/play", "precompile"] }
}
task deleteDirs(type: Delete) {
delete 'precompiled', 'tmp'
}
//NOW, assemble needs to zip up directories precompiled, public, lib, and conf
clean.dependsOn('deleteDirs')
I don't get why the eclipse one is not running every time and seems to work just fine while overridding the compile one is not working.
It is very important to understand the distinction between task configuration and task execution:
task eclipsify {
// Code that goes here is *configuring* the task, and will
// get evaluated on *every* build invocation, no matter
// which tasks Gradle eventually decides to execute.
// Don't do anything time-consuming here.
doLast {
// `doLast` adds a so-called *task action* to the task.
// The code inside the task action(s) defines the task's behavior.
// It will only get evaluated if and when Gradle decides to
// execute the task.
exec { commandLine = ["./play1.3.x/play", "eclipsify"] }
}
}
// Improving on the previous task declaration, let's now use a *task type*
// (see `type: Exec` below). Task types come with a predefined task action,
// so it's typically not necessary to add one yourself. Also, many task types
// predefine task inputs and outputs, which allows Gradle to check if the task
// is up-to-date. Another advantage of task types is that they allow for
// better tooling support (e.g. auto-completion of task properties).
task precompile(type: Exec) {
// Since this task already has a task action, we only
// need to configure it.
commandLine = ["./play1.3.x/play", "precompile"] }
}
If you don't get configuration vs. execution right, you'll see symptoms such as very long startup times and tasks seemingly getting executed when they shouldn't.
To learn which task types are available and how to configure them, check out the Gradle Build Language Reference. Besides, there is an ever-growing list of third-party plugins and task types.
PS: I changed the task names and removed the overwrite: True
(which should only be used as a last resort) to not distract from the main message of my answer.
Gradle does not know that your source was not changed. For any unknown status it marks the task as not up-to-date. Since your task is 100% replacement of compile
, then it is your responsibility to provide the status of the task.
Writing Custom Task Classes chapter provides details on how to get started with incremental tasks.
Run your project with --info
flag to see why Gradle is marking compile
task as not up-to-date.
Hope it helps.