This message was deleted.

Note that behaviour is the same with a composite

Yes, because you are invoking the

build

task of project

:A

. To fulfill the requirement of

:A:build

, Gradle only need to compile

:B

not test. You should use

./gradlew build

instead to build everything or

./gradlew :A:build :B:build

to build both project.

mmh ok, still seems awkward to me. I would expect

A:build

to depend on

B:build

and not

B:compile

; I would expect my build to check whether my compiled dependencies pass tests when their sources have changed. For a composite build, it would induce that if I want to build or deploy part of my application, it is not safe to run build only on part of the composite (I could indeed specify every deps and transitive deps on command line, but if I’ve got many of them, it is error-prone). Is this design only about performance? I hardly imagine a use-case of building an application with silenced failing tests on shared code for instance

At least for Java project there are also

buildNeeded

and

buildDependents

that might run what you want: https://docs.gradle.org/current/userguide/java_plugin.html#lifecycle_tasks

It's not actually build that depends on B's compile but build that depends on the current project's assemble which depends on the jar which depends on compile which depends on the api of B. It's a matter of what the lifecycle task means for the project. Each plugin reference page should have this information.

Gradle is designed to avoid work wherever possible. To build

A

what is necessary are the classes of

B

. Given

B

applies the

java-library

plugin, building

A

does not even trigger building the

jar

of

B

, but only compiling its sources to classes as that is all that is necessary to compile the classes of

A

. If

A

is for example applying the

application

plugin and you run its

build

task, then the

distZip

and

distTar

tasks also need the

jar

of

B

, so also the

jar

is built, but still no tests as these are simply not necessary for the requested task. But Gradle is convention-over-configuration, meaning it has sane conventions that the developers deem good for the average case, but enough flexibility to make a build however you like it. So if you want

A:build

to depend on

B:build

, declare it. Or if you want to depend

B:jar

on

B:check

so that tests and other check tasks are always done before the

jar

is build, declare it. The defaults are simply chosen to avoid work wherever possible, so that a developer build can finish as fast as possible. Of course for the "price" of then needing to invoke what you want to do like

gradlew build

to call the

build

task on all projects and thus also the

check

tasks, or

gradlew check

to call the check tasks on all projects.

@Anze Sodja Yes that is a good point and is somehow similar to maven options also-make and also-make-dependencies; anyway I use Kotlin. I believe that would be nice built-in Gradle features. @daniel @Vampire Ok, got it! I’ll add dependencies between tasks to get the workflow I would like ; I hope that will not be hard to maintain, or I might find/write an equivalent to buildNeeded/buildDependents of the java plugin. Thank to you all 🙂