There are a multitude of ways to control the Gradle dependency resolution process. Is there any guidance or best practices for organizing Gradle builds to support automated dependency vulnerability remediation via tools like dependabot? If we assume the tool already has access to resolved dependencies and knows the non-vulnerable version required for the fix, how do we organize the Gradle build to enable the tool to create a successful pull request?

I'd use a version catalog and if you insist on using such bots, then at least Renovate instead of Dependabot.

What alternatives are there to using such bots?

I don't like my pull-requests spammed with continuous minor version updates and also don't want to handle dozens of pull-requests each week. But if a project does not handle them, it easily appears to be unmaintained, whether it is or not.

I'm not so interested in staying up-to-date with the latest available versions. I want to resolve vulnerabilities as soon as feasible. Most of the time, a simple version upgrade is all that's required. What I'm finding is all of the bots rely on versions explicitly specified in the Gradle files somewhere. If you use a BOM in a platform to manage versions and the BOM contains a vulnerable dependency, then the bots can't help you. The same is true for transitive dependencies. The bots don't understand Gradle dependency management. They only try a search and replace. Other than explicitly specifying the version for all direct and transitive dependencies in a project, I'm wondering what approaches others have taken or if there is some best practice around this?

If that is true, I'd report a bug against those tools. If they want to properly support Gradle, they should use the tooling API to get the versions used in the project. But actually, Ben Manes versions plugin is a Gradle plugin and it uses the dependency resolution of Gradle to find new versions, basically by copying configurations, using "latest" versions for things and then resolving them. So approaches like that should properly work including any dependency resolution configuration you can make. But also that afair only checks the versions of things you depend on, not transitive dependencies.

arbitrary build scripts are turing-complete so there's no guaranteed way to change a version

Maybe not to change, but at least to detect

well there's no guarantee that an arbitrary build script will depend on the same version more than once either 😉

I didn't get that

but yeah as long as there's no strange module metadata rules or resolution strategies or

withDependencies

mutation, things should be pretty normal

> arbitrary build scripts are turing-complete so there's no guaranteed way to change a version But can we be successful in a large percentage of cases? Are there rules we can follow to increase success?

a goal of #C06JG95HREY is to make editing builds mechanical and reliable

But can we be successful in a large percentage of cases?

Sure, but if you want to use a specific tool that updates the versions for you, then make sure you use things that are compatible with that tool.