Dependencies declared in a version catalog should be declared in a separate manifest

[bigdaz]

Attributing these to the subproject where they are referenced is unhelpful to users attempting to update the dependency version.

[JLLeitschuh]

I still believe that the manifest should be an accurate reflection of what is resolved. If GitHub wanted to know what was explicitly declared, they already have tools in Dependabot to look at the source code directly

[bigdaz]

I still believe that the manifest should be an accurate reflection of what is resolved.

Understood. But my understanding is that GitHub designed the protocol intending that a manifest should as much as possible represent a set of dependencies declared in a single source file, together with all of the transitive dependencies.

I completely agree that the overall graph submission should represent what is actually resolved. It shouldn't include anything that wasn't resolved, and shouldn't exclude anything that was resolved. But as much as possible I think that each manifest entry should represent a single place where dependencies are declared, since this will provide a better user experience with GitHub.

In the end, the GitHub Dependency Graph file is solely intended for consumption by GitHub. Producing other, more comprehensive output formats is entirely possible but shouldn't necessarily influence our mapping to the GitHub format.

[bigdaz]

After discussing with the GitHub Dependency Graph team, we've decided to go with a single manifest per build invocation. This fits better with their current implementation (and their vision), and will make it much easier to adapt this functionality on a wider scale (and enable by default in gradle-build-action).

Closing this issue as not longer relevant.