Enable :reason task to get reason for specific gradle capabilities (e.g. testFixtures)

[Nava2]

Describe the solution you'd like
Some form of CLI parameters that enables specifying which gradle capability that is cared about. Such that, only that capability is shown.

For example,

./gradlew :project:reason --id ':other-project' --capability 'com.example:other-project-test-fixtures'

Describe alternatives you've considered
Add notation to siginify which capability an output belongs to if there are multiple usages. For example, showing that content comes from testFixtures vs. default.

Alternately, including all capabilities in the output of just --id ':other-project' would work!

Additional context

[autonomousapps]

I don't entirely follow this request. Could you share a sample of the expected output from such a feature?

[Nava2]

This may be user error, but if you have a build that leverages java-test-fixtures (Docs), it will add a dependency on a project with a capability rather than the normal project.

If you want to look at the "reason" output, i.e. figure out why that dependency is used in the project, there's no way to request it specifically today. Calling --id ':other-project' will return all usages from all capabilities.

Edit: I had the output wrong in my initial comment, but it still stands that there's no way to differentiate teh different capabilities/artifacts.

[Nava2]

Here's a project: https://github.com/Nava2/dependency-analysis-test-fixtures-project-example

$ ./gradlew :lib:reason --id ":other-project"

> Configure project :
WARNING: Unsupported Kotlin plugin version.
The `embedded-kotlin` and `kotlin-dsl` plugins rely on features of Kotlin `1.9.20` that might work differently than in the requested version `1.9.22`.

> Task :lib:reason

----------------------------------------
You asked about the dependency ':other-project'.
There is no advice regarding this dependency.
----------------------------------------

Shortest path from :lib to dependency-analysis-test-fixtures-project-example:other-project for compileClasspath:
:lib
\--- dependency-analysis-test-fixtures-project-example:other-project

Shortest path from :lib to dependency-analysis-test-fixtures-project-example:other-project for runtimeClasspath:
:lib
\--- dependency-analysis-test-fixtures-project-example:other-project

Shortest path from :lib to dependency-analysis-test-fixtures-project-example:other-project for testCompileClasspath:
:lib
\--- dependency-analysis-test-fixtures-project-example:other-project

Shortest path from :lib to dependency-analysis-test-fixtures-project-example:other-project for testRuntimeClasspath:
:lib
\--- dependency-analysis-test-fixtures-project-example:other-project

Source: main
------------
(no usages)

Source: test
------------
* Uses 1 class: com.example.dependency_analysis.TestFixture (implies testImplementation).

I'm unsure how to get advice for why the testFixture(project(":other-project")) is applied

[Nava2]

@autonomousapps I added some more context, I had my initial question incorrect as the test fixture content is there. It's just not marked/obvious what is coming from where. I updated the initial description and my previous comment! Apologies for confusion.

[autonomousapps]

@jjohannes this might be something interesting for us to take a look at.

[Nava2]

The capability information appears to be in the JSON output, so I hope this is just a visualization change 😅

[arthurrogel]

Hey, just noting here, I ran into this same issue today, the parameter proposed by @Nava2 would definitely be helpful to me as well!

[seregamorph]

This seems to be related #1170