Sebastian Schuberth

> On a related note, there's [a tree-based API for resolution of Maven project dependencies](http://maven.apache.org/shared/maven-dependency-tree/) which might solve the problem Looks like we'd need to use its [DefaultDependencyCollectorBuilder](https://maven.apache.org/shared/maven-dependency-tree/apidocs/org/apache/maven/shared/dependency/graph/internal/DefaultDependencyCollectorBuilder.html) instead of...

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 dislike the ever expanding scope of ORT I'm also a bit skeptical here... esp. when going as far as checking for things like inclusive language. > for compliance...

Please also rebase this onto latest `origin/main` to benefit from some test fixes / updates.

Thanks @itrich for the update! Now for the sake of maintaining a clean Git history, please squash all your commits into one (the first one). PS: Instead of catching up...

> Now for the sake of maintaining a clean Git history, please squash all your commits into one (the first one). Thanks for the squash @itrich, however now we have...

@itrich was the closing of this intended?

Superseded by https://github.com/oss-review-toolkit/ort/pull/5878.

Thanks for this through proposal, @JorisVanEijden! Unfortunately, we cannot foresee yet when one of us will have the time to implement it.

> starting with replacing composer version 1 currently in the default docker image with composer version 2. Unfortunately, the latest Composer version in Ubuntu Focal (which we currently base our...