With ./gradlew dependencies, I get only the root project’s dependencies.
(Which is particularly silly in my case, because the root project does not have code.)
How do I make Gradle display the dependencies of subprojects?
I’d like to see those of all projects, and those of any specific subproject.
N.B.: I am pretty sure that I’m overlooking something trivial, but I saw no useful clues in gradle help and gradle help --task dependencies so I’m stuck.
Complications that may or may not affect the answer:
FWIW I am using test-fixtures-plugin, which preconfigures additional dependency source sets.
FWIW 2 one subproject uses test fixture code from another one, i.e. I have things like testFixturesImplementation(":other-project") in my build.gradle.kts.
If using a build --scan is an option, it gives a nice overview.
If it must be the dependencies task, it is a bit special compared to other tasks in that it does not have the “execute everywhere available” semantics like other tasks, so dependencies behaves identical to :dependencies.
If you want to execute for project with path :foo:bar, use :foo:bar:dependencies.
If you want the execute everywhere semantics there are some options. You can call ./gradlew -q projects, and process the result to append :dependencies to each project path and then call Gradle again with those task paths. Or you could configure the dependencies task in the root project to depend on the dependencies tasks of all subprojects, but in a stringy way, not by racing into the other projects models. Or you could register in all projects a task of the type of dependencies but with a different name, then it behaves exactly like and other task, as this special behavior is bound to the task name, not type.
Hm. Some questions to help me get a deeper understanding of what’s going on:
Any particular reason why dependencies does not extend to subprojects like the other commands do?
The naming convention strikes me as odd.
Let’s say I have a subproject :foo with both a subproject and a task named bar, :foo:bar seems ambiguous, it could be the subproject or the task in :foo.
Is this an oversight, or is there a design reason behind that?
Or am I simply misunderstanding something? (Entirely possible.)
Any particular reason why dependencies does not extend to subprojects like the other commands do?
No idea, ask Gradle folks that decided it.
But I guess the most usual use-case is that you only want the dependencies for one project and also as it by default shows the dependencies of all configurations which can already be overwhelming and multiplying that by showing it for all projects might make it way worse.
Also, if you request a certain configuration maybe it is not available everyhwere.
Of course you can mitigate all that by requesting a specific one of the tasks, so .
The naming convention strikes me as odd.
It’s not really ambiguous, as they are different things.
One thing is the path of a project, the other thing is a path of a task.
So yes, the task bar in the sub project bar of the project foo would be :foo:bar:bar,
and :foo:bar could mean the subproject bar of the project foo, or the task bar in the project foo.
But by the usage this is usually unambiguous as you either use it as a task path or as a project path.
And also it is quite uncommon that it happens that a project has the same name as a task.
.