Why does this make things easier? More to type, adds extra indirection (I have to look into an extra file to check what I'm including), the file format isn't the simplest, and `ext` properties are also accessible by subprojects, and the Spring BOM plugin provided a similar feature. But I don't want to be so negative about it, usually I welcome new changes, and this one has upsides too. The new approach is more systematic and less programmatic, and a core feature of Gradle. It reduces arguments about how to define versions without repetitions. I just wish they have made it more compelling for me. Thanks for the info!
Yeah they're good points! For existing projects there might not be any compelling reason to swtich. I'm just glad this has been made into a proper feature now with an obvious starting point for new projects.
@@TomGregoryTech Do you know by any chance why this change seems so "not gradle"? Any other thing you do in gradle can be done with groovy/kotlin and is relatively easy. You can decide where to put what and how to organize your gradle files, including and so on. Something along the lines of rootProject.versionCatalog { mockito("1.14.3") { "a.b.c:mockito-core" "a.b.c:mockito-inline" } } subproject dependencies { api catalog("mockito") } This would allow the standard gradle freedom
This is very useful with multi module projects, also we replace multiple dependencies with single line if we use dependency bundle. Hope to see more from Tom
What exactly should I put in my toml file? I see that you added version number and libaries in this video. How about config variables like compile and min sdk?
You can add [versions], [libraries], [bundles], and [plugins]. There are also different ways to specify the version e.g. strictly. See the docs for full details docs.gradle.org/current/userguide/platforms.html#sub:conventional-dependencies-toml
I think that's should be good for projects with large amounts of dependencies, e.g. Also, putting dependencies versions directly on buildscript always sounded "hardcoding" for me. In terms of organizing project this feature should be fine. If you need to define versions and even dependencies names this can be the way. Old days I used to use .properties file, but I see that its purpose is other scope. Btw, simple project with few dependencies maybe don't needs this. In the end is always a tradeoff. 😅
Hi. Thanks for checking out the video. I haven't used it before, but have a look at the Gradle Versions Plugin which can print a dependency update report github.com/ben-manes/gradle-versions-plugin
After a year, can we see something like a Spring Boot project using Kotlin as both codebase and DSL? I'm interested in how to play with the plugins section specially when it has something besides `id` like `java` or `kotlin`
Nice video. Between this approach and Gradle's dependency locking feature, do you have any experience which works best (especially for a multi module project)?
@Tom Gregory Thanks for responding. Haven't tried it yet. I actually learned about it yesterday that I bumped into a subreddit discussing the easiest way to manage and auto-update gradle dependencies, and these two features came up. To be honest, they do seem like both could solve this problem. Which one do you think is more suitable?
@@theanswer3sixers It depends on your use case. Yes, version catalogs are good for managing dependencies. For auto-update you could look at declaring version ranges or if you're on GitHub try out Dependabot.
Hi Tom , we have few of our jars whose name starts with capital letters and while executing the gradle build I get this following error " org.gradle.api.InvalidUserDataException: Invalid catalog definition. Reason : Library aliases must match the following regular expressions : [a-z]([a-zA-Z0-9_.\-]). Do you have any idea how can I solve this problem without changing the jar name or is there any way to resolve this via gradle files ? BTW I am also using this libs.versions.toml file concept. It works fine for jars whose name follows the regex pattern but gives an error for the jar whose name starts with Capital letter.
Why does this make things easier? More to type, adds extra indirection (I have to look into an extra file to check what I'm including), the file format isn't the simplest, and `ext` properties are also accessible by subprojects, and the Spring BOM plugin provided a similar feature. But I don't want to be so negative about it, usually I welcome new changes, and this one has upsides too. The new approach is more systematic and less programmatic, and a core feature of Gradle. It reduces arguments about how to define versions without repetitions. I just wish they have made it more compelling for me. Thanks for the info!
Yeah they're good points! For existing projects there might not be any compelling reason to swtich. I'm just glad this has been made into a proper feature now with an obvious starting point for new projects.
@@TomGregoryTech Do you know by any chance why this change seems so "not gradle"?
Any other thing you do in gradle can be done with groovy/kotlin and is relatively easy. You can decide where to put what and how to organize your gradle files, including and so on.
Something along the lines of
rootProject.versionCatalog {
mockito("1.14.3") {
"a.b.c:mockito-core"
"a.b.c:mockito-inline"
}
}
subproject
dependencies {
api catalog("mockito")
}
This would allow the standard gradle freedom
This is very useful with multi module projects, also we replace multiple dependencies with single line if we use dependency bundle.
Hope to see more from Tom
What exactly should I put in my toml file? I see that you added version number and libaries in this video. How about config variables like compile and min sdk?
You can add [versions], [libraries], [bundles], and [plugins]. There are also different ways to specify the version e.g. strictly. See the docs for full details docs.gradle.org/current/userguide/platforms.html#sub:conventional-dependencies-toml
How to reference Catalog from buildSrc scripts?
Nice video Tom. Is there any advantages of using catalogs instead of declaring dependencies and versions in Kotlin files inside buildSrc folder?
Hi Douglas. It's a single source of truth for dependency versions. You can also declare bundles of dependencies.
I think that's should be good for projects with large amounts of dependencies, e.g. Also, putting dependencies versions directly on buildscript always sounded "hardcoding" for me. In terms of organizing project this feature should be fine. If you need to define versions and even dependencies names this can be the way.
Old days I used to use .properties file, but I see that its purpose is other scope.
Btw, simple project with few dependencies maybe don't needs this. In the end is always a tradeoff. 😅
Hi Tom, great video but how can I still get notified when there's a newer release of the dependencies included in the toml file?
Hi. Thanks for checking out the video. I haven't used it before, but have a look at the Gradle Versions Plugin which can print a dependency update report github.com/ben-manes/gradle-versions-plugin
Thanks for the video, Tom added toml file Lol
After a year, can we see something like a Spring Boot project using Kotlin as both codebase and DSL? I'm interested in how to play with the plugins section specially when it has something besides `id` like `java` or `kotlin`
great video so useffuly
Nice video. Between this approach and Gradle's dependency locking feature, do you have any experience which works best (especially for a multi module project)?
Hi. Did you try dependency locking yet? Its purpose is different to version catalogs. There's no reason you can't use both together.
@Tom Gregory Thanks for responding. Haven't tried it yet. I actually learned about it yesterday that I bumped into a subreddit discussing the easiest way to manage and auto-update gradle dependencies, and these two features came up.
To be honest, they do seem like both could solve this problem. Which one do you think is more suitable?
@@theanswer3sixers It depends on your use case. Yes, version catalogs are good for managing dependencies. For auto-update you could look at declaring version ranges or if you're on GitHub try out Dependabot.
Thanks, this was very helpful.
Where we put that fucking file . Gradle doesnt see
1. Switch the view of Android Studio to project view.
2. Put it inside the gradle folder.
Rofl
Hi Tom , we have few of our jars whose name starts with capital letters and while executing the gradle build I get this following error " org.gradle.api.InvalidUserDataException: Invalid catalog definition.
Reason : Library aliases must match the following regular expressions : [a-z]([a-zA-Z0-9_.\-]).
Do you have any idea how can I solve this problem without changing the jar name or is there any way to resolve this via gradle files ?
BTW I am also using this libs.versions.toml file concept. It works fine for jars whose name follows the regex pattern but gives an error for the jar whose name starts with Capital letter.
Hi Kevin. I haven't seen this error before. I would try the code based approach (i.e. in settings.gradle) and see if you get the same problem.