Can the report show project name for each dependencies?

[amimas]

I applied this plugin to my root project's build.gradle to get an aggregated report in a multi module Gradle project. It's very useful at first glance.

Then I started to notice some dependencies that I didn't recognize or they are not declared in any of Gradle project's dependencies. So, these must be transitive dependencies. It took a bit of time for me to track down which one of my dependency pulled in that particular transitive dependency.

It'd be nice if the dependency will show some additional metadata in the report:

• Is it a transitive dependency or not
  • corresponding main dependency
• the corresponding project name

This could get a bit complicated if multiple dependencies pulls in the same version of the same transitive dependency.

[jk1]

This could get even more complicated with a dependency tree of arbitrary length. The described feature is actually quite close to the built-in Gradle dependency task and/or build scan features.

[guenhter]

Showing the full dependency tree with gradle for the whole multi-module-project is quite simple: https://solidsoft.wordpress.com/2014/11/13/gradle-tricks-display-dependencies-for-all-subprojects-in-multi-project-build/

I usually pipe the output to a file and then do my investigations.

[amimas]

I think showing the full dependency tree became even simpler now with Gradle's built in project-report plugin.

https://docs.gradle.org/current/userguide/project_report_plugin.html

I just thought it might be easier for the end user if the license report could point out which subproject each dependency belongs to; maybe a comma separated list of project names. That way the end user doesn't have to go through another report and perform manual analysis. But I do understand the implementation may not be as simple.

[guenhter]

Yesterday I exactly had the same "issue" to find out where a dependency comes from. It would not only be interesting which project, but also in which configurations this dependency is included. Maybe a first step is to improve the data model to hold the information. From there, the renderer can then respect or ignore that information.

[amimas]

This feature would be very helpful indeed.

Maybe one way to handle it would be to apply gradle's project-report if it's not applied already. And then parse the report generated by that plugin and incoroporate that into this plugin's report.

Or, maybe there's more easier/better way.

[guenhter]

@jk1 what do you think of this? Would it improve the data model to have the information where a dependency comes from (which project and which configuration)?

[jk1]

@guenhter I guess we can add it to the model. Several things to keep in mind:

1. There may be multiple sources for each dependency
2. Dependency resolution strategy may get in our way. Since we examine the project when everything is already resolved we may see something quite different from what's written in dependencies block
3. Imported modules provide no information on where the dependency comes from