CODEWITHSUNDEEP
javagroovygradle
insidesin
insidesin

Reputation: 743

How to order the 'running' of configuration tasks in Gradle?

I've currently got a configuration task being depended on by an execution task that I am calling from command-line, i.e.

task deployTest(dependsOn: [build, assembleForTest]) << {
    ...
}

This task should essentially grab the files I've assembled in assembleForTest and then deploy them (ssh, etc.)

My assembleForTest code:

task assembleForTest(type: Sync) {
    fileMode = 0775
    from ("scripts") {
        include "**/*.cgi"
        filter(org.apache.tools.ant.filters.ReplaceTokens, 
        tokens: [programName: programName, 
                 version: version, 
                 dbServer: dbServerTest,
                 deployDir: deployDirTest])
    }
    from files("scripts/" + programName + ".cgi") 
    from files("build/libs/" + programName + "-" + version + ".jar")
    into ("build/" + programName)   
}

But the problem is: My project gets built AFTER this configuration task assembleForTest has run. i.e. it will try build after the assembly is finished, which means an outdated (or nonexistant) deployment is attempted.

Gradle has some of the worst documenting I've seen, I have worked with it for a while and I still don't understand the ideal setup.

Upvotes: 0

Views: 1494

Answers (1)

topr
topr

Reputation: 4612

Wouldn't that solve your problem?

task assembleForTest(type: Sync, dependsOn: build) {
    /* configuration phase, evaluated always and before execution phase of any task */
    ...
}

task deployTest(dependsOn: assembleForTest) << {
    /* execution phase, evaluated only if the task is invoked and after configuration phase for all tasks has been finished */
    ...
}

EDIT: I added comments within example. Note that the 1st task is provided with configuration while the 2nd is provided with action. The switch is done with left shift operator. Alternative syntax, especially helpful to combine both phases definition, looks as follows:

task plop() {
    // some configuration
    ...
    doLast {
        // some action
        ...
    }
}

If you put println in place of 'some configuration' it prints always regardless what task is invoked, as that's evaluated in configuration phase.

Upvotes: 1

Related Questions