https://docs.gradle.org/current/userguide/dependency_locking.html#sec:lock-all-configurations-in-one-build-execution We have this very task defined and applied to our builds through an in-house conventions plugin. Now gradle is warning us that it will no longer work as of gradle 10, as it references

project

during task execution. I don't really see any way to get a hold of the

StartParameters

and all the configurations except through the

Project

. Does anyone have a suggestion?

Have you tried writing that task as a custom task (vs the inline stuff), as that can make the Project dependency more obvious? Also, sometimes the inline stuff has implicit Project/script references.

I did write it as a custom task. After a bit of cleanup, the task action now looks like this:

@TaskAction
public void run() {
    if (!getProject().getGradle().getStartParameter().isWriteDependencyLocks()) {
        throw new IllegalArgumentException("--write-locks is required when running this task");
    }
    if (getResetLocks().get()) {
        getFileSystemOperations().delete(spec -> spec.delete(getDependencyLockingHandler().getLockFile()));
    }
    getProject().getConfigurations().stream()
            .filter(Configuration::isCanBeResolved)
            .forEach(Configuration::resolve);
}

so I have 2 project reference remaining which I don't really know how to get rid of: •

getProject().getGradle().getStartParameter()

•

getProject().getConfigurations()

the first one can be passed as a task property, e.g.

myTask {
   writeDependencyLocks = gradle.startParameter.writeDependencyLocks
}

Perhaps configurations can also be passed in at configuration time. I'm pretty sure they should be available at that time as well. Thanks for the pointer!

@Chris Lee is correct. If you refactor your Task to have some input parameters for those values, you'll be able to remove the runtime project dependency.