Hi. There's a problem with gradle when generating...
# community-support
h
Hi. There's a problem with gradle when generating lockfile for the dependencies that are imported/applied from another file into build.gradle file. Suppose all the dependencies are declared in
libraries.gradle
, and are imported to
build.gradle
using `apply from: `libraries.gradle`` . However, when I try to generate the lockfile for the project using
./gradlew --write-locks dependencies
, the gradle.lockfile doesn't include the dependencies. Is there any alternative way that can be used to include dependencies?
v
I don't use locking, so not sure on that part, but I'd say it should work, no matter where the dependencies come from as long as they are resolved during the write locks call. But using "apply from" and thus legacy script plugins is highly discouraged and has quite some quirks anyway you sooner or later will hit, so you shouldn't use them at all anyway. If you just want to define a bunch of libraries you can apply with one line, I'd use a verison catalog with a bundle, then you can just use the bundle to add all the dependencies.
h
Okay. How do I make sure that dependencies are resolved during the write locks call?
Like are there any directives that I can write to the
build.gradle
file before generating lock file that'll make sure of all the dependencies getting included in the lockfile?
h
Couldn't grasp the solution properly. Is there any other way?
n
what don't you grasp? the listing in
example 5
gives a task action that resolves all dependencies when writing lockfiles:
Copy code
configurations.filter {
            // Add any custom filtering on the configurations to be resolved
            it.isCanBeResolved
        }.forEach { it.resolve() }
h
i don't know why but this code from the example didn't work when i ran it for my project
n
We're using it in dozens of projects successfully, so perhaps it's worth investigating why it doesn't function in your specific case?
h
Dependencies are declared inside of
project.ext
block in another file. I think there's some co-relation, not sure.
v
While that sounds like multiple bad-practices combined, it should not influence the result. If done inside a task action at execution time it should work properly. If not, then you might miss configurations added later.