How could a dependency show up in the dependencies target but not in the configuration?

(Justin Ryan) #1

I have a transitive dependency which shows up fine in the dependenies task output, but when actually executing tasks, it’s not in the configuration’s list of files. I’ve looked in configurations.testRuntime.resolvedConfiguration.resolvedArtifacts, and the module just isn’t there, yet it’s in the dependencies task view.

If I add the transitive dependency directly, it then shows up in testRuntime. This hints that the problem isn’t related to a problem identifying the artifact/jar for the module, since Gradle will download it if in the configuration.

There’s a mismatch between the artifacts in the configuration vs what the dependencies task shows. Knowing the difference will help me diagnose why the module is missing.

(Justin Ryan) #2

I can more precisely say that the transitive is in configurations.testRuntime.incoming.resolutionResult.allDependencies but not configurations.testRuntime.resolvedConfiguration.resolvedArtifacts. What’s a short description of the difference between the incoming and a resolvedConfiguration?

(Peter Niederwieser) #3

‘Configuration.incoming’ is a newer, richer API that may eventually replace ‘Configuration.resolvedConfiguration’. ‘incoming.resolutionResult.allDependencies’ is a dependency graph whose nodes are (resolvable and unresolvable) modules (we call them module versions). ‘resolvedConfiguration.resolvedArtifacts’ is a flattened set of resolved artifacts.

(Justin Ryan) #4

Thanks for the explanation Peter. In the end, I was running into a problem with defaultconfmappings which causes the wrong confs to be used, resulting into no artifacts. So the incoming accurately reflected the dependency, and the resolveArtifacts was showing missing the artifacts, since there were none to be found (in the conf Gradle was looking at).