Can the report show project name for each dependencies? about gradle-license-report HOT 7 OPEN

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.

from gradle-license-report.

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.

from gradle-license-report.

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.

from gradle-license-report.

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.

from gradle-license-report.

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.

from gradle-license-report.

@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)?

from gradle-license-report.

@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

from gradle-license-report.