This message was deleted.

I - and most projects I know - prefer using concrete versions. And with concrete versions there is no point in using dependency locking. Dependency locking mainly makes sense if you declare dynamic versions, but still want reproducible builds.

I've started using dependency locking at my org recently. We were having a lot of issues where our SCA tools were flagging dependencies as containing vulnerabilities which failed our builds. It was a lot of manual effort to constantly be updating dependencies to their newest versions. dependency locking allows us to build jenkins pipelines to run periodically that update the lockfile with the newest versions and opens PRs. I have dealt with a good amount of configuration difficulties with dependency locking but I've been happy with it. I would love a way to have concrete versions but an automatic way to update them at the patch, minor, or major level.

I usually use the

versions

plugin of ben manes to display what updates are available and the

refreshVersions

plugin to update the versions. For me this is a pretty convenient combination and not a pain at all to update versions. There are also other plugins available that can update versions, and work together with the

versions

plugin for example to create PRs. Or if you use

GitHub

for your code, you can use the Renovate bot if you want such PRs I don't like at all, or the not so good Dependabot.

Thanks for those recommendations @Vampire! Will check those plugins out.

Thanks! I also use dependabot in one of my open source projects.

Sometimes dependency locking is used by external tools to determine the actual dependencies of a project, because it's easier than trying to parse the build scripts https://snyk.io/blog/security-testing-git-based-gradle-projects-lockfile/

Which is both bad. The tooling API should be used to get the information. That's the only really reliable source.