Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locked and non-resolving configurations fail with an error in Gradle 7.x with a single project #128

Closed
ebickle opened this issue Apr 5, 2024 · 1 comment · Fixed by #129
Assignees
Labels
bug Something isn't working
Milestone

Comments

@ebickle
Copy link

ebickle commented Apr 5, 2024

When using Gradle 7.6.4 with a dependency locking enabled and a single project build, the error Locking strict mode: Configuration ':archives' is locked but does not have lock state. occurs and the build fails. Setting DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS=archives causes the same error to occur but on the :default configuration instead.

Running ./gradlew dependencies shows that both the archives and default configurations are non-resolving. The gradle.lockfile does not include any references to either configuration, likely because they are non-resolving. The problem only occurs in a 'single project build' (e.g. without a settings.gradle file or where the settings.gradle file does not include any valid child projects).

build.zip

Attached is a very simple Gradle project to reproduce the issue:

  1. Install the latest version of Gradle 7.x: gradle wrapper --gradle-version 7.6.4

  2. Generate a lockfile: ./gradlew dependencies --write-locks

    • Notice that 'archives' and 'default' configurations have an (n) after them, indicating they are non-resolving.
    • Notice that the empty= line in gradle.lockfile does not include archives or default on the empty= line. This appears to be correct behavior since they are non-resolving configurations.
  3. Run the github-dependency-graph-gradle-plugin using the command from this repo's README. Alternately, using the GitHub dependency submission action causes the same behavior. ./gradlew -I init.gradle --dependency-verification=off --no-configuration-cache --no-configure-on-demand :ForceDependencyResolutionPlugin_resolveAllDependencies

The following error is returned:

Task :ForceDependencyResolutionPlugin_resolveProjectDependencies FAILED
(omitted)
Execution failed for task ':ForceDependencyResolutionPlugin_resolveProjectDependencies'.
Could not resolve all dependencies for configuration ':archives'.
Locking strict mode: Configuration ':archives' is locked but does not have lock state.

Environment details:

openjdk version "1.8.0_402"
OpenJDK Runtime Environment Corretto-8.402.08.1 (build 1.8.0_402-b08)
OpenJDK 64-Bit Server VM Corretto-8.402.08.1 (build 25.402-b08, mixed mode)

Windows 11 Version 23H2 (OS Build 22631.3296)

gradle --version (used to initialize the wrapper, but not used for executing the Gradle commands above)
Gradle 8.7
Revision: 650af14d7653aa949fce5e886e685efc9cf97c10

Although this was tested with OpenJDK 8, we observed similar behavior in OpenJDK 17. We've temporarily worked around the issue by including both archives and default in the DEPENDENCY_GRAPH_EXCLUDE_CONFIGURATIONS environment variable, but since we're deploying the Gradle Dependency Submission action throughout the enterprise we'll be encountering a variety of 'single project' Gradle builds that aren't upgraded to 8.x yet.

@bigdaz bigdaz self-assigned this Apr 5, 2024
@bigdaz bigdaz added the bug Something isn't working label Apr 5, 2024
@bigdaz
Copy link
Member

bigdaz commented Apr 5, 2024

Thanks for the detailed report and the reproducer. I need to investigate why we're attempting to resolve an unresolvable configuration.

@bigdaz bigdaz closed this as completed Apr 5, 2024
@bigdaz bigdaz reopened this Apr 6, 2024
bigdaz added a commit that referenced this issue Apr 6, 2024
bigdaz added a commit that referenced this issue Apr 6, 2024
bigdaz added a commit that referenced this issue Apr 6, 2024
Certain configurations can be reported as "Deprecated for resolving", 
which is detectable via the`DeprecatableConfiguration.canSafelyBeResolved` internal API.

Resolving these configurations during dependency graph generationg can
be problematic, particularly in the case of strict Dependency Locking,
since no lockfile is likely to be generated for these configurations.

With this fix, reflection is used to attempt to determine if a
Configuration can be safely resolved, avoiding resolution of deprecated
configurations.

Fixes #128
@bigdaz bigdaz added this to the v1.3.1 milestone Apr 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants