You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Version Catalogs provide the ability to centrally define your dependency versions rather than defining the versions multiple times across various sub projects. This also has the added benefit of easily been able to up-version a dependency using tools like depend-a-bot.
I'd like to see adoption of version catalogs be driven through gradle doctor to encourage this by warning (and optionally failing the build) when it detects that a version has been defined directly within a build.gradle(.kts) file
The text was updated successfully, but these errors were encountered:
Might be out of scope for Gradle docker in that it won't make your builds faster. Just helps to keep them tider and less errorprone.
We can detect it since you end up with the version number in the string when you defined a dependency.
If the dependency is managed with a BOM there is no version number. The version catalog will import it via an accessor (if I've got the right name for it)
Version Catalogs provide the ability to centrally define your dependency versions rather than defining the versions multiple times across various sub projects. This also has the added benefit of easily been able to up-version a dependency using tools like depend-a-bot.
I'd like to see adoption of version catalogs be driven through gradle doctor to encourage this by warning (and optionally failing the build) when it detects that a version has been defined directly within a build.gradle(.kts) file
The text was updated successfully, but these errors were encountered: