beforeTask/afterTask execution time - immediately before/after?


(Magnus Rundberget) #1

(Gradle 1.6) I have a multiproject which applies a plugin with one task. There is no dependencies between the projects. I’ve added a beforeTask and afterTask closure for the plugin task.

Lets call my subprojects sub1, sub2 and sub3 and the task in question myTask and that they have a println for the beforeTask config, beforeTask config and a println for the task action it self.

When I call the task from the root folder the output would typically be somthing like:

“sub1 beforeTask” “sub2 beforeTask” “sub3 beforeTask” “sub1 executing” “sub2 executing” “sub3 executing” “sub1 afterTask” “sub2 afterTask” “sub3 afterTask”

Is this to be expected ? In the dsl doc it says the before/after closures will be executed immediately before/after the task is executed. I guess thats not entirely true in a multi project setup ? If its intentional I would suggest modifying the doc :slight_smile:

cheers Magnus


(Peter Niederwieser) #2

I cannot reproduce this output, unless running with ‘–parallel’. Is that what you are doing?


(Magnus Rundberget) #3

I’ve never set paralell and can’t see that its set in gradle_opts either.

The project in question: https://github.com/rundis/gradle-buster-plugin

To reproduce (if not specific to my environment ): 1) $gradle-buster-plugin: gradle build -xintegtrationTest 2) $gradle-buster-plugin/exampleMult: gradle busterTest -i

(Don’t worry about the errors you’ll get, I’m guessing you don’t have buster installed, but that’s beside the point here).


(Peter Niederwieser) #4

I’m not sure what’s going on here, but as soon as I remove the ‘exec’ code that makes things fail for me, the order of output is as expected. At present, my best guess is that this is an output problem, rather than an order of execution problem. In any case, you don’t want to do anything expensive in callbacks like ‘beforeTask’/‘afterTask’. Instead this should be done in regular tasks, possibly involving ‘finalizedBy’.


(Magnus Rundberget) #5

weird stuff. I’m pretty sure it failed because it tried to start a second server before the first task had finished executing. My machine syndrome perhaps.

Anyways I’ve moved starting and stopping of server to a service and invoke setup/teardown from within the relevant tasks.

Tx for looking into it.

cheers Magnus