Issue type

Wrong or misleading information

Problem description

The docs for 'Selectively updating lock state entries' give an example command:

gradle classes --update-locks org.apache.commons:commons-lang3,org.slf4j:slf4j-api

This is bad advice.

Suppose you have 1 locked dependency:

org.apache.commons:commons-lang3:3.12.0=compileClasspath,runtimeClasspath,testCompileClasspath,testRuntimeClasspath

You update build.gradle.kts to 3.13.0 and copy-paste the command from the docs. The command passes. But the result is incorrect:

-org.apache.commons:commons-lang3:3.12.0=compileClasspath,runtimeClasspath,testCompileClasspath,testRuntimeClasspath
+org.apache.commons:commons-lang3:3.12.0=runtimeClasspath,testCompileClasspath,testRuntimeClasspath
+org.apache.commons:commons-lang3:3.13.0=compileClasspath

Instead of updating the lock to 3.13.0, the command created a bug where a different version is used for compiling and for running, causing NoClassDefFoundError etc. if you write your code to call the newest additions to the library. I just checked this using Gradle 8.8.

Proposed solution

Change the code example to use 'dependencies' task instead of 'classes' task:

gradle dependencies --update-locks org.apache.commons:commons-lang3,org.slf4j:slf4j-api

Benefits:

1. Gives correct results, no matter which configurations you lock and which you don't lock
2. Is consistent with the task chosen in other call on the same page:

Run gradle dependencies --write-locks. This will effectively lock all resolvable configurations

3. Is faster, by avoiding compilation (not needed to resolve dependencies)

Context (optional)

No response

Page with the problem

https://docs.gradle.org/8.8/userguide/dependency_locking.html#selectively_updating_lock_state_entries