-
-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Gradle 7.4 Version Catalogs #333
Comments
Hello, this is already in the mental backlog. A few things in the incubating versions catalog feature makes it that it'd not allow to have an ideal experience with refreshVersions, but it's still planned to experiment with it and most likely send feedback to Gradle on it, so it keeps incubating towards "a grown up feature". |
I have a plan to combine versions catalog and refreshVersions. I updated the issue with my notes |
Gradle 7.4, freshly released, finally brings improvements and stabilization for version catalogs, which is helping us move this issue forward. First step is coming in #504: that one will still work with the version placeholder. However, we understand that the initial request is about supporting plain version catalogs, that contain the versions. It is technically possible since TOML supports comments, so we'll consider it after #504 is behind us. |
I've got news! cc @DanySK @beski @JSSchneider @NikkyAI and all. I implemented support for versions catalog:
It's published in the snapshot version Have a look at the Testing? pargraph from the pull-request #509 |
it would be really nice if this could make use of the especially versions like kotlin version repeat a lot for example with this rule (and the builtin rules for kotlin):
i would expect smth like this in the versions catalog [versions]
kotlin = "1.5.31"
## # available:1.6.20-M1"
## # available:1.6.20-RC"
kord-extensions = "1.5.1-RC1"
[libraries]
com-korlindiscord-kord-extensions-kord-extensions = { module = "com.kotlindiscord.kord.extensions:kord-extensions", version.ref = "kord-extensions" }
com-korlindiscord-kord-extensions-annotations = { module = "com.kotlindiscord.kord.extensions:annotations", version.ref = "kord-extensions" }
com-korlindiscord-kord-extensions-annotation-processor = { module = "com.kotlindiscord.kord.extensions:annotation-processor", version.ref = "kord-extensions" }
org-jetbrains-kotlin-multiplatform-gradle-plugin = { module = "org.jetbrains.kotlin.multiplatform:org.jetbrains.kotlin.multiplatform.gradle.plugin", version.ref = "kotlin" }
org-jetbrains-kotlin-plugin-serialization-gradle-plugin = { module = "org.jetbrains.kotlin.plugin.serialization:org.jetbrains.kotlin.plugin.serialization.gradle.plugin", version.ref = "kotlin }
grouping versions together at the top of the file, deduplicating the places where things have to get edited.. (thats the point of refreshVersions anyways) |
Gradle 7.0 introduced the "centralized declaration of dependencies".
Namely, dependencies can be aliased, grouped, and versioned in a TOML file.
It would be incredibly nice if refreshVersions could target the
libs.versions.toml
file in future, rather than relying on a customversion.properties
.Update: notes from jmfayard
the plan for now is not to give up
versions.properties
it's to auto-generate the libraries versions catalog, with the placeholder version
_
and use the typesafe accessors to help migrate an existing project to refreshVersionsRunning
$ ./gradlew refreshVersionsCatalog
wouldgradle/libs.dependencies.toml
$ ./ gradlew refreshVersionsMapping
Documentation
The text was updated successfully, but these errors were encountered: