How to use the same locked dependencies among all sub-projects


We have a multi-project build running the latest version of Gradle, v6.0.1. Each sub-project declares its own dependencies along with any restrictions necessary for the project to run properly. We wish for all of our code to compile and run with the same dependencies in both testing and production.


As part of our build pipeline we ensure dependency resolution can succeed with proper conflict resolution and then lock all dependencies. However, we recently realized that sub-projects were not compiling with the locked dependencies. This is because each sub-project looks for dependency locks in its own gradle/dependency-locks directory and we are only generating these file in our root project.

For instance we notice discrepancies such as

$ ./gradlew :dependencies | grep this-is:a-dependency | sort -u | head -n1
+--- this-is:a-dependency:2.0

$ ./gradlew :some-subproject:dependencies | grep this-is | sort -u | head -n1
|   \--- this-is:a-dependency:1.0

How to Fix?

An easy fix is to create a custom task that copies the root project’s dependency lock directory into each sub-project’s dependency lock directory before compile time. However this feels somewhat hacky. Is there a more proper way to achieve the desired result?


I’ve fixed some dependency versions for all configurations by iterating over all dependencies of all configurations like this:

I’ve copied and adapted this and would also like to know if there is a reason not to do it like this. Possibly tools do not take this statement into consideration when running a vulnerability analysis or checking for updates.


Hi Marco,

How would this sync dependencies such that sub-projects would use the correct dependencies? I do not see any way this could be used to achieve the desired goal.

Let me know if I am missing something.


Hi Aaron, this forces all subprojects to use the same version of particular dependencies instead of defining them per subproject. That’s how I understood your original request. Greetings Marco

However we want our sub-projects to define their own dependencies. This is more modular and allows them to be passed around among different projects.