Does it provide Latest versions for libraries in Dependency tree ?

[jagan23527001]

Do plugin provides the latest versions for sub libraries used within dependency block ?

Example for sub dependencies -

+--- org.springframework.cloud:spring-cloud-config-client:3.0.2 | | +--- org.springframework.boot:spring-boot-autoconfigure:2.4.2 | | | --- org.springframework.boot:spring-boot:2.4.2 | | | +--- org.springframework:spring-core:5.3.3 | | | | --- org.springframework:spring-jcl:5.3.3 | | | --- org.springframework:spring-context:5.3.3 | | | +--- org.springframework:spring-aop:5.3.3 | | | | +--- org.springframework:spring-beans:5.3.3 | | | | | --- org.springframework:spring-core:5.3.3 () | | | | --- org.springframework:spring-core:5.3.3 () | | | +--- org.springframework:spring-beans:5.3.3 () | | | +--- org.springframework:spring-core:5.3.3 () | | | --- org.springframework:spring-expression:5.3.3 | | | --- org.springframework:spring-core:5.3.3 (*)

[ben-manes]

Currently this is not supported and we disable transitive dependencies in our resolution queries. Therefore only dependencies declared explicitly within your build are shown in the report. It also means that if a transitive dependency would cause an upgrade (e.g. dependency has a later version of guava), the report will show your declared version instead of the runtime version. This behavior is a little more obvious and straightforward, and matches Maven's versions:display-dependency-updates task.

The feature could be added for an extended report by an options flag. If you're interested then a PR is welcome. The resolution logic is handled by Resolver.groovy.

[jagan23527001]

Thanks Ben, Really Great work. Let me check in resolver.groovy, if i can add it.

[ben-manes]

You'll want to dig a bit into the Gradle APIs. When we use ResolvedConfiguration#getFirstLevelModuleDependencies(), that returns a Set<ResolvedDependency>. These are your declared dependencies and you can recurse using ResolvedDependency#getChildren() for its set of resolved dependencies. Eventually you'll gather everything for both the current and latest configurations to report on, and can forward that to the existing logic. You might want to enhance the reporting a bit to indicate direct vs transitive dependencies, and the transitive dependencies that would be added or removed between if upgrading. Once you look at the API docs and experiment a little, I think the logic should be simple and more work will be on keeping the report understandable.