Gradle 4.X tooo parallel, plz fix

Guys, Gradle 4.X parallelism is ruining my life. What is happening? Are task dependencies just a partial ordering over the actions within tasks now?

I have custom task A, it makes some files
I have custom task B, it eats some files

I can’t make this work reliably since gradle keeps trying to delete files and/or run these actions at the same time. I’m just setting org.gradle.parallel=false before I hang myself.


1 Like

Hi Eric,

did you declare that your custom task A outputs the files and custom task B eats the files? Something like

TaskA extends DefaultTask {
    File outputDir
TaskB extends DefaultTask {
    File dirToDelete

This should make sure that the two tasks run in the desired order. For more information please have a look at the userguide.


The docs don’t discuss this in much detail at all, so that link doesn’t help.

I have declared output directories in TaskA
I have declared input directories in TaskB which reads these files, it does not delete.

I am at a loss of what I need to do that at all, if TaskA.dependsOn TaskB. Can I disable whatever feature of gradle it is that wants these very, very, VERY, annoying annotation. If TaskA depends on TaskB I want all of TaskA before TaskB, not part of it?

Is it the case TaskA.dependsOn TaskB is a partial ordering now?

Is there some part of gradle aggressively trying to scrub files from the disk? I want that off too… really un helpful stuff

There has not been any change in meaning to TaskA.dependsOn TaskB. It means that Gradle cannot start executing any actions of TaskA until TaskB is complete.

I think you mean that TaskA has input directories that come from the output directories of TaskB (and TaskA.dependsOn TaskB)?

Would it be possible for you to generate a build scan for the build in question when it has the problem? We would be able to see on the timeline view if TaskA/TaskB are really overlapping or if there’s another task executing at the same time.

If you can’t create a build scan, would it be possible for you to reduce your build into a reproducible example of the problem?

Are any of the tasks marked as @CacheableTask or task.outputs.cacheIf { true }?

Are the output directories shared with any other task? e.g., if TaskB’s output directory was build/classes/java/main, that would overlap with compileJava.

No, it means the same it has always meant: B must run before A.

If this does not work for you, please provide a reproducible example.