How can I call a task from another task (with dependencies)

Old Forum
1

I have a set of tasks arranged in a DAG. Many of the tasks depend on a parameter “product” set at the top of the script. I want to invoke the main (head?) task multiple times, varying this parameter.

def product // current product def products = [“full”, “lite”, “demo”] task all << {

products.each {

p ->

product = p

headTask.execute()

} }

The problem is that when I call headTask.execute(), its dependencies do not execute.

I think perhaps I could solve this with task rules, but since many of the tasks in the chain depend on “product”, I’d also have to make my dependsOn attribute like a rule.

There must be a more gradle-like way of doing this. Anyone have a suggestion?

1 Like
2

Calling ‘execute()’ on tasks is not supported at all. It’s not clear what you are trying to achieve so I’m unable to offer a suggestion on how to proceed.

3

I’m trying to build multiple installers for my product in one go. There’s a Full-featured version of the product, the Lite version, and the Demo version. I want to filter my installer-generating script (NSIS), and then assemble the appropriate files for each version and put it in an appropriately named directory. So in the end I’ll have the files in /CoolApp-5.3/Full, /CoolApp-5.3/Lite, /CoolApp-5.3/Demo, each with a different installer and slightly different set of files.

In the old pre-Gradle (Ant) days, I’d generate the Full version, manually create the /CoolApp-5.3/Full directory, and copy the files by hand. Then I’d edit the installer file, run it again to generate the Lite version, then create the Lite dir and copy the files by hand, etc. Because of course it’s crazy difficult to do loops in Ant.

What I was hoping to do with Gradle was eliminate all the manual steps in my build. I wanted to say “gradle buildAll” and have it loop through the three product configurations one-by-one, filtering the installer correctly and putting the files in their final resting place.

Basically it means I want to run the entire build script three times, with a different set of parameters each time. I could certainly go “gradle doIt -Dversion=full”, then “gradle doIt -Dversion=lite”, etc. but I was sure hoping to just put the loop in the build script itself.

4

You could consider implementing buildAll as a task that dependsOn 3 independent tasks of type:Zip, zipFull, zipLite, zipDemo, and use a copySpec to refactor any duplication.

5

I found a workaround to do this. In my scenario I have a task that reads an user input and depending on his anwser I need to create a EAR with different configurations. I used a task of type GradleBuild. Here is the code:

task createEar() << {
           def wichTypeOfEar = System.console().readLine("Which EAR?? (a, b)\n")
            if(wichTypeOfEar == 'a'){
            tasks.earA.execute()
        }else{
            tasks.earB.execute()
        }
        }
      task earA(type: GradleBuild) {
        doFirst{
        // Here I can do some stuffs related to ear A
        }
        tasks = ['ear']
    }
          task earB(type: GradleBuild) {
        doFirst{
        // Here I can do some stuffs related to ear B
        }
        tasks = ['ear']
    }
      ear {
       //Here is the common built in EAR task from 'ear' plugin
    }

In you case you could do the following:

task testNGTests(type: Test) {
        useTestNG()
        }
      task testNGTestsWrapper(type: GradleBuild){
        tasks = ['testNGTests']
    }
      task taskA {
        doFirst {
     testNGTestsWrapper.execute()
        }
    }