[Question] Inconsistent gradle configuration exclusion results

[Pil0tXia]

I want to analyze the dependencies of runtimeClasspath only. I have tried the following methods:

• DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: runtimeClasspath, log, dependency graph artifact size: 563 Bytes (empty, no deps in it)
• DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS: '.*[Tt]est(Compile|Runtime)Classpath', log, dependency graph artifact size: 18.2 KB (almost full deps in it, 18.3 KB when no exclusion applied)
• DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS: '.*(testCompile|testRuntime|compile)Classpath', log, dependency graph artifact size: 16.8 KB (jupiter with testImplementation scope still in it although test exclusion declared)
• DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: '[Ii]mplementation.*|[Rr]untime.*|[Cc]ompile.*|[Aa]pi.*|[Aa]nnotation.*', log, dependency graph artifact size: 10.9 KB (jupiter not in it finally, but lombok with compileOnly scope is still in it)
• DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: '[Ii]mplementation.*|[Rr]untime.*|[Aa]pi.*', log, dependency graph artifact size: 563 Bytes (empty, no deps in it)

I am not clear about the reasons. I think I will temporarily use DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: '[Ii]mplementation.*|[Rr]untime.*|[Cc]ompile.*|[Aa]pi.*' to analyze the dependencies of runtimeClasspath (i.e., the dependencies bundled when packaging as a binary release), but compileOnly scope deps are not excluded with this regex.

[bigdaz]

Since this is a public project, I strongly recommend that you publish Build Scans for your dependency submission actions. This will give you a good overview of which configurations are resolving the dependencies in question. It's difficult to get this sort of overview otherwise, since the way dependencies are declared and how they are resolved is different.

Another mechanism is to run the dependencies for each subproject in your project, since this task only reports on resolvable configurations.

Note that configurations named implementation and api are not resolvable.

[bigdaz]

I'd also recommend that you use the dependency-submission action to generate the dependency graph, since this will attempt to resolve all resolvable configurations by default.

Instead, you're generating a dependency graph based on running the clean assemble compileTestJava tasks: since you're not running the tests I suspect this doesn't require the *[rR]untimeClasspath configurations to be resolved at all. That would explain the empty graph when trying to include this configuration!

[Pil0tXia]

Great! I tired to use dependency-submission instead of setup-gradle, it works exactly what I want with DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: '[rR]untimeClasspath' (log). Thanks a lot.

It seems that the deps generated by setup-gradle depends on its task, and runtimeOnly deps are only available in build task.

However, DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS: '[tT]estCompileClasspath|[tT]estRuntimeClasspath|[cC]ompileClasspath' doesn't have any effect (log).

[bigdaz]

Did you try generating a build scan? If you share that I can help explain why you're seeing this behaviour. Without it I'm just guessing.

[Pil0tXia]

@bigdaz I'll try to generate one maybe tomorrow and then I'll update it under this post. 😊

[bigdaz]

I see now that Develocity (Gradle Enterprise) is already enabled for apache/eventmesh. All you need to do is supply the access key when running the dependency-submission action.

I really recommend you do that, so that you'll get Build Scans for each workflow run on an ongoing basis. However, since you won't have the access key configured in your fork, you won't be able to publish build scans to ge.apache.org until the code is merged.

So for now, try re-running your PR workflow with action debugging enabled. The process is described here: https://github.com/gradle/actions/blob/main/docs/dependency-submission.md#when-you-cannot-publish-a-build-scan. This will tell you which dependencies are resolved in which configurations.

[Pil0tXia]

@bigdaz

Thank you for instruction. I've re-ran the job with the DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS: '[tT]estCompileClasspath|[tT]estRuntimeClasspath|[cC]ompileClasspath' exclusion (log) and the job with the DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS: '[rR]untimeClasspath' exclusion (log).

I briefly compared the logs of the two and it seems that only the latter outputs the following log:

Excluding resolved configuration from dependency graph: ...

I will try to publish a build scan maybe latter.

[bigdaz]

Thanks for sharing those jobs. If you download the logs for each and search for "Detected dependency" you'll find:

• 109,281 matching lines in the first job
• 41,865 matching lines in the second job.

This shows that exclusion is removing some dependencies from those that are considered, but you must consider that many of the "Detected dependencies" are duplicated in multiple configurations. It's very likely that the every dependency excluded in the second job is also present in a configuration that wasn't excluded. This could be due to all of the 'detachedConfiguration*' configurations: I suspect these are created by the Spring Dependency Management plugin. Maybe try excluding those as well.

[Pil0tXia]

@bigdaz Thanks for the analysis. That is, detachedConfiguration reintroduces the dependencies I want to exclude. So maybe using DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS is the best practice?

[bigdaz]

I'm not sure it's "best practice". The Spring Dependency Management plugin introduces a bunch of detachedConfiguration instances: perhaps one for every dependency you have declared?
It's up to you if you want to selectively include or excluded, but I'd probably choose to exclude these detachedConfiguration instances. You risk missing more actual dependencies if you selectively include.

[bigdaz]

@Pil0tXia Are you OK with closing this issue? It would be great if you reply with a solution that works for you.

[Pil0tXia]

Since my purpose of using Dependency Gragh is to review third-party dependency licenses in binary distributions in conjunction with dependency-review-action, include would probably be more suitable for my scenario.

However, this solution is not applicable due to an unresolved bug of dependency-review-action.