I’ve been a fan of the Gradle build tool from quite early on. Its potential was clear even before the 1.0 version, when changes were regularly breaking. Today, upgrading rarely cause surprises. The tool has become mature and performs well.
Gradle includes a powerful dependency management system that can work with Maven and Ivy repositories as well as local file system dependencies.
During my work with Gradle I’ve come to rely on a pattern for managing dependencies in a multi-project build that I want to share. This pattern consists of two key practices:
- Centralize dependency declarations in
build.gradle - Centralize dependency version declarations in
gradle.properties
Both practices are examples of applying software development best practices like DRY to the code that makes up the Gradle build. Let’s look at them in some more detail.
Centralize dependency declarations
In the root project’s build.gradle file, declare a new configuration for each dependency used in the entire project. In each sub-project that uses the dependency, declare that the compile (or testCompile, etc) configuration extends the configuration for the dependency:
Root project build.gradle
subprojects {
configurations {
commonsIo
}
dependencies {
commonsIo 'commons-io:commons-io:2.5'
}
}Sub-project build.gradle
configurations {
compile.extendsFrom commonsIo
}By putting all dependency declarations in a single place, we know where to look and we prevent multiple sub-projects from declaring the same dependency with different versions.
Furthermore, the sub-projects are now more declarative, specifying only what logical components they depend on, rather than all the details of how a component is built up from individual jar files. When there is a one-to-one correspondence, as in the commons IO example, that’s not such a big deal, but the difference is pronounced when working with components that are made up of multiple jars, like the Spring framework or Jetty.
Centralize dependency version declarations
The next step is to replace all the version numbers from the root project’sbuild.gradle file by properties defined in the root project’s
gradle.properties:
build.gradle
dependencies {
commonsIo "commons-io:commons-io:$commonsIoVersion"
}gradle.properties
commonsIoVersion=2.5
This practice allows you to reuse the version numbers for related dependencies. For instance, if you’re using the Spring framework, you may want to declare dependencies on spring-mvc and spring-jdbc with the same version number.
There is an additional advantage of this approach. Upgrading a dependency means updating gradle.properties, while adding a new dependency means updating build.gradle. This makes it easy to gauge from a commit feed what types of changes could have been made and thus to determine whether a closer inspection is warranted.
You can take this a step further and put the configurations anddependencies blocks in a separate file, e.g. dependencies.gradle.
And beyond…
Having all the dependencies declared in a single location is a stepping stone to more advanced supply chain management practices.
The centrally declared configurations give a good overview of all the components that you use in your product, the so-called Bill of Materials (BOM). You can use the above technique, or use the Gradle BOM plugin.
The BOM makes it easier to use a tool like OWASP DependencyCheck to check for publicly disclosed vulnerabilities in the dependencies that you use. At EMC, about 80% of vulnerabilities reported against our products are caused by issues in 3rd party components, so it makes sense to keep a security eye on dependencies.
A solid BOM also makes it easier to review licenses and their compliance requirements. If you can’t afford a tool like BlackDuck Protex, you can write something less advanced yourself with modest effort.
| Reference: | How to manage dependencies in a Gradle multi-project build from our JCG partner Remon Sinnema at the Secure Software Development blog. |
what if have more than one common dependencies?