The simply way how buildscript dependencies (e.g. plugins) can be displayed and analyzed in Gradle
Introduction
This is the third part of my Gradle tricks mini-series related to visualization and analyze of dependencies. In the first post I presented a way how dependencies for all subprojects in multi-project build can be display. In the second I showed a technique of useful in tracking down not expected transitive dependencies in the project. This time less often used things, yet crucial in specific cases – buildscript dependencies.
Real use case
Buildscript dependencies contains plugins used in our project and their dependencies. It would seem nothing interesting unless you are a Gradle plugin developer, but it is not completely true. Once, as a consultant, I was investigating issue with NoSuchMethodException in a large project with custom build framework built on top of Gradle. The problem occurred only when one innocent, very popular open source plugin had been adding to the project. The same plugin worked fine in many other project in that company. In the end I was able to figure out that one of the dependencies used in buildSrc custom scripts overriding the same dependencies in older version from the plugin. As a result plugin failed at runtime with mentioned NoSuchMethodException. To achieve that I had to use my custom script as buildscript/classpath dependencies are completely ignored when ./gradlew dependencies or ./gradlew dependencyInsight is used.
Solution
The idea to write this post arose in at the beginning of 2015. I wanted to present my small Gradle task that using some internal Gradle mechanisms retrieves buildscript dependencies in display them to a console. The post was postponed and almost a year later I was positively surprised reading release notes for Gradle 2.10. The new buildEnvironment task was added.
$ ./gradlew buildEnvironment
:buildEnvironment
------------------------------------------------------------
Root project
------------------------------------------------------------
classpath
+--- com.bmuschko:gradle-nexus-plugin:2.3
\--- io.codearte.gradle.nexus:gradle-nexus-staging-plugin:0.5.3
\--- org.codehaus.groovy.modules.http-builder:http-builder:0.7.1
+--- org.apache.httpcomponents:httpclient:4.2.1
| +--- org.apache.httpcomponents:httpcore:4.2.1
| +--- commons-logging:commons-logging:1.1.1
| \--- commons-codec:commons-codec:1.6
+--- net.sf.json-lib:json-lib:2.3
| +--- commons-beanutils:commons-beanutils:1.8.0
| | \--- commons-logging:commons-logging:1.1.1
| +--- commons-collections:commons-collections:3.2.1
| +--- commons-lang:commons-lang:2.4
| +--- commons-logging:commons-logging:1.1.1
| \--- net.sf.ezmorph:ezmorph:1.0.6
| \--- commons-lang:commons-lang:2.3 -> 2.4
+--- net.sourceforge.nekohtml:nekohtml:1.9.16
\--- xml-resolver:xml-resolver:1.2
(*) - dependencies omitted (listed previously)
BUILD SUCCESSFUL
Total time: 1.38 secsTwo plugins and a pack of transitive dependencies to gradle-nexus-staging-plugin thanks to http-builder (maybe it would be good to replace it with Jodd?).
Summary
It is worth to be able to distinguish standard projects dependencies and buildscript dependencies. The new buildEnvironment task helps to deal with the latter. This in turn becomes essential when strange runtime errors start to show up.
Tested with Gradle 2.10.
| Reference: | Gradle tricks – display buildscript dependencies from our JCG partner Marcin Zajaczkowski at the Solid Soft blog. |
