Changing one dependency declaration can have unexpected side effects through its transitive dependencies. For an example of tightly-coupled dependencies, let’s look at a simple Spring Boot project with the following build.gradle file.
We declare the Spring Boot dependencies bill-of-materials (BOM) as a platform dependency. After creating a build scan, we can see that the BOM itself is marked as a platform and all the constraints are applied. Here, we also see that the version of Spring Boot starter web which does not specify a particular version matches the version specified by the BOM.
That’s all great when the versions are all the same, but what happens when you want to include a bugfix that’s only available in a newer version of one of the transient dependencies, for example, Spring Boot Starter JSON? Adding a dependency definition with the most recent version (2.1.8.RELEASE) to the build.gradle file will trigger conflict resolution between the dependencies of Spring Boot starter test and the specified version of Spring Boot starter JSON.
Since, 2.1.8.RELEASE is a higher version, Gradle will select it, and because it’s only defined in the test implementation configuration, it won’t affect the version of that dependency used in the compile and runtime configurations.
In the build scan, we see several other versions were updated too. Expanding the JSON dependency detail view shows that there are several transient dependencies. Two of those dependencies are the Spring Boot Starter Web and Spring Boot Starter Test, which in turn have many other dependencies meaning our small change to one dependency now updates most of the project.
These changes could cause the build to suddenly start failing when a new version is published. With Gradle Enterprise build comparisons, you can then compare this build to the last one to see which dependencies have changed.
These are just some of the questions build scans can help you answer about the dependencies in your project. You can also query within subprojects, look at constraints from custom java platforms, see rich dependency version constraint information, identify cyclic dependency reference, and more as described in the Gradle Enterprise 2019.3 release notes.
These new features are already available on individual scans builds published to scans.gradle.com (except for build comparison, which is a Gradle Enterprise only feature). Existing Gradle Enterprise customers can upgrade to 2019.3 to take advantage of these new features. For assistance upgrading, please contact your account representative. For enterprise development teams looking to try Gradle Enterprise free for 30 days, you can submit a trial request.