Failures during dependency resolution seem to be swallowed

[sschuberth]

I'm not sure whether it's supposed to be like that, but what I see it that running ./gradlew dependencies on https://github.com/wkl3nk/demo-7 gives

dependencySources
+--- org.jetbrains.kotlin:kotlin-stdlib:2.0.0
+--- org.projectlombok:lombok -> 1.18.32
+--- org.springframework.boot:spring-boot-starter-security -> 3.3.0
+--- org.springframework.boot:spring-boot-starter-web -> 3.3.0
+--- com.fasterxml.jackson.module:jackson-module-kotlin FAILED
\--- org.jetbrains.kotlin:kotlin-reflect:2.0.0
     \--- org.jetbrains.kotlin:kotlin-stdlib:2.0.0

So there is a resolution failure in jackson-module-kotlin and inspecting that further with ./gradlew dependencyInsight --dependency jackson-module-kotlin --configuration dependencySources gives:

> Task :dependencyInsight
com.fasterxml.jackson.module:jackson-module-kotlin: (selected by rule) FAILED
   Failures:
      - Could not resolve com.fasterxml.jackson.module:jackson-module-kotlin.
        No matching variant errors are explained in more detail at https://docs.gradle.org/8.8/userguide/variant_model.html#sub:variant-no-match.
          - No matching variant of com.fasterxml.jackson.module:jackson-module-kotlin:2.17.1 was found. The consumer was configured to find sources for use during runtime, packaged as a jar, preferably optimized for standard JVMs, and its dependencies declared externally, as well as attribute 'org.jetbrains.kotlin.platform.type' with value 'jvm' but:
              - Variant 'apiElements' declares a component, packaged as a jar, and its dependencies declared externally:
                  - Incompatible because this component declares a library for use during compile-time and the consumer needed documentation for use during runtime
                  - Other compatible attributes:
                      - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
                      - Doesn't say anything about org.jetbrains.kotlin.platform.type (required 'jvm')
                      - Doesn't say anything about the documentation type (required sources)
              - Variant 'runtimeElements' declares a component for use during runtime, packaged as a jar, and its dependencies declared externally:
                  - Incompatible because this component declares a library and the consumer needed documentation
                  - Other compatible attributes:
                      - Doesn't say anything about its target Java environment (preferred optimized for standard JVMs)
                      - Doesn't say anything about org.jetbrains.kotlin.platform.type (required 'jvm')
                      - Doesn't say anything about the documentation type (required sources)

However, when running this plugin's ForceDependencyResolutionPlugin_resolveAllDependencies on that project, dependency-graph.json is created just fine without any issues, but jackson-module-kotlin is simply omitted from the dependencySources configuration.

So my questions are:

• Is there actually a (configuration) issue in that project?
  • If there is an issue in the project, why does ForceDependencyResolutionPlugin_resolveAllDependencies no report it as part of dependency-graph.json?
  • If there is no issue in the project, why does Gradle's dependencies task to report a failure?
• Given "the consumer needed documentation for use during runtime", who the heck needs documentation at runtime? 🤓

[bigdaz]

It is intended that the plugin will report all resolved dependencies, and ignore any that fail to resolve. This allows us to resolve each and every dependency configuration in the project without having the graph generation fail if one of these is not fully resolvable.

As far as I know, there's no mechanism to include a resolution failure in the generated GitHub dependency graph, although it would be possible to include this in some custom reporting. That would involve changing this method so that UnresolvedDependencyResult values are also captured and reported.

To answer your specific questions:

Is there actually a (configuration) issue in that project?

The dependencies report indicates an issue fully resolving the dependencySources configuration. This is only a problem if your project attempts to resolve this configuration directly, without making the resolution "lenient". I don't know why your project has a dependencySources configuration or how it is used.

If there is an issue in the project, why does ForceDependencyResolutionPlugin_resolveAllDependencies no report it as part of dependency-graph.json?

As described above, the plugin reports all resolved dependencies, and ignores ones that cannot be resolved. There's no way for the current dependency-graph to include a resolution failure, and we don't want to fail the build when one is encountered.

[sschuberth]

there's no mechanism to include a resolution failure in the generated GitHub dependency graph

That's quite unexpected, at least from my side. I've filed github/dependency-submission-toolkit#78 about it.

I don't know why your project has a dependencySources configuration or how it is used.

This seems to have been automatically introduced by a switch to Kotlin 2.0.0 in the project.

[sschuberth]

This seems to have been automatically introduced by a switch to Kotlin 2.0.0 in the project.

Looks like the issue with unresolvable dependencySources configurations will be fixed in Kotlin 2.0.20.