Open sschuberth opened 2 years ago
On a related note, there's a tree-based API for resolution of Maven project dependencies which might solve the problem, and we should consider using it instead of our low-level approach. That library apparently also does only download the POMs which would allow us to get rid of our work-around.
On a related note, there's a tree-based API for resolution of Maven project dependencies which might solve the problem
Looks like we'd need to use its DefaultDependencyCollectorBuilder instead of the DefaultDependencyGraphBuilder, as that's what the maven-dependency-plugin
uses in "verbose" mode, see https://github.com/apache/maven-dependency-plugin/commit/d9d34c6674db6c9a5c0786c95d0caf96bc9636fb.
Another interesting Maven artifact resolver implementation to look at is https://github.com/square/maven-archeologist. It also points out https://github.com/google/guava/wiki/GraphsExplained which might be an alternative for our own dependency graph implementation.
I just verified that ORT's analyzer suffers from the same problem as CycloneDX's Maven plugin: The Maven resolver library might de-duplicated dependencies that have already been reported, resulting in an incomplete tree for some (direct) dependencies.
While at first the discussion in that issue makes it sounds like a pure upstream maven issue, the question remains why apparently the depgraph-maven-plugin gets it right nonetheless.