This message was deleted.

A build scan will answer that for you, but it most likely happens because

A:jar

runs after

A:test

and is required by

B:test

We are looking into changing that in Gradle 7.5 by saying that

test

shouldRunAfter

jar

.

aha brill thank you, yes excluding the jar task allows them to run in parallel

Just make sure you execute the

jar

task separately in a Gradle run before then. Or

B:test

is pretty meaningless if it works with an outdated JAR, or can even fail if the JAR is not present and due to the exclusion also is not created.

https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:meta_inf_normalization Could help as well.

How could that help here?

To handle 'up-to-date' checks for `jar`s.

But that is absolutely not helpful. 1. you linked the meta inf normalization which does not apply at all here 2. even if you consider the chapter before, it is about runtime classpath normalization. so it does not influence the up-to-date check of the

jar

task, it influences the normalization of runtime classpath inputs of tasks using the result of the

jar

task, so that for example a

test

task does not need to run again just because the version in a properties file changed that is not relevant for testing and similar things 3. and even if it would influence the

jar

task up-to-date check - which it does not -, the

B:test

task would still need to wait until the

jar

task finished to see that it is up-to-date.

You are correct, my bad. Sorry for that.