gradle dependencies
allows to display Dependencies in your project printed as pretty ascii tree. Unfortunately it does not work well for submodules in multi-project build. I was not able to find satisfactory solution on the web, so after worked out my own that blog post arose.
Multiple subprojects
For multi-project builds gradle dependencies
called in the root directory unexpectedly displays no dependencies:
No dependencies displayed for the root project
In fact Gradle is right. Root project usually has no code and no compile or runtime dependencies. Only in case of using plugins there could be some additional configurations created by them.
You could think about --recursive
or --with-submodules
flags, but they do not exist. It is possible to display dependencies for subprojects with “gradle sub1:dependencies
” and “gradle sub2:dependencies
“, but this is very manual and unpractical for more than a few modules. We could write a shell script, but having regard to (potential) recursive folders traversal there are some catches. Gradle claims to be very extensible with its Groovy based DSL, so why not take advantage of that. Iteration over subprojects can give some effects, but after testing a few conception I ended with pure and simple:
subprojects { task allDeps(type: DependencyReportTask) {} }
When called gradle allDeps
it executes dependencies
task on all subprojects.
Dependencies for all subprojects
Remove duplication
All dependencies belong to us, but some parts of the tree looks similar (and duplication is a bad thing). Especially configurations default
, compile
and runtime
and the second group testCompile
and testRuntime
in most cases contain (almost) the same set of dependencies. To make the output shorter we could limit it to runtime
(or in case of test dependencies testRuntime
). dependencies
task provides convenient parameter --configuration
and to focus on test dependencies “gradle allDeps --configuration testRuntime
” can be used.
Dependencies in one configuration for all subprojects
Summary
Where it could be useful? Recently I was pair programming with my old-new colleague in a new project (with dozens submodules) where SLF4J in addition to expected slf4j-logback
provider discovered on a classpath also slf4j-simple
. We wanted to figure out which library depends on it. Logging dependencies tree to file with a help of grep gave us the answer.
As a bonus during my fights with DependencyReportTask
I found an easier way how get know who requires given library. I will write about it in my next post.
Tested with Gradle 2.2.
This post first appeared on Solid Soft | Working Code Is Not Enough, please read the originial post: here