Delayed task configuration


(steve) #1

In our build we have some very expensive code that needs to run to fully configure the javadoc task. We’d like to delay that configuration until it is known that the javadoc task is actually part of the execution graph. The “expensive code” basically looks at every class included in the javadoc task source and determines its package name - it does this in order to define proper groups based on our standardized package name conventions. That takes a lot of time and adds significant overhead to our build init.

IIUC this could have been handled by Gradle’s “model” feature, but that is still incubating years later and I’d rather not keep relying on perpetually incubating features.

Any ideas? Since this does not affect UP-TO-DATE checks, is it enough to simply use something like gradle.taskGraph.whenReady{ project.tasks.javadoc{ (groups stuff) } }?


(Stefan Wolf) #2

Hi Steve,

Why don’t you add a configureJavadoc task which configures the javadoc task in a doLast? Another option would be to do the extra work and finalize the configuration of the javadoc task in a doFirst block on the javadoc task itself.

Cheers,
Stefan


(steve) #3

Because I didn’t realize you could do that :wink: I will try that, thanks!


(Chris Doré) #4

Keep in mind that any configuration of the javadoc task that impacts the javadoc task’s inputs could cause bad or broken incremental build behaviour if done during the javadoc task’s execution (ie. during a doFirst).


(steve) #5

Yep, groups would only change if classes change which would already trigger
re-running the javadoc task


(steve) #6

@Stefan_Wolf That worked like a champ! Thanks!


(Stefan Wolf) #7

Great to hear!

Note that I second @Chris_Dore’s remark: If you go for a doFirst on the javadoc task itself, make sure you don’t change/add any inputs to the task, since they won’t be tracked by Gradle and this may lead to incorrect incremental builds.