In this chapter, you learned how Gradle resolves dependencies and how to customize this. You saw how to reconfigure your build scripts to handle transitive dependencies and how to resolve version conflicts between dependencies in your builds. Gradle offers some fine-grained control on how we define dependencies and allows very explicit dependency definitions.

For transitive dependencies, we have several ways to redefine which dependencies need to be used by either disabling or excluding transitive dependencies.

When a version conflict arises between dependencies in our build, we can either rely on the default strategy of using the newest version or implement a custom strategy. Gradle has several ways to customize dependency resolution rules by redefining the resolution strategy. For example, we can override the version attribute for a dependency or even totally replace it with a compatible but different dependency.

Finally, you saw how the dependency cache of Gradle works. It is designed to reduce network requests and provide reliable and repeatable builds that have dependencies. You learned how you can customize the expiration time for dependency modules that are changing or are defined with dynamic versions.

Up until now, we saw how to include dependencies in our projects, but in the next chapter, we will see how we can publish artifacts that we created as dependencies for other projects.