Skip to content
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

Closed
DanySK opened this issue Apr 28, 2021 · 6 comments · Fixed by #509
Closed

Add support for Gradle 7.4 Version Catalogs #333

DanySK opened this issue Apr 28, 2021 · 6 comments · Fixed by #509

Comments

@DanySK
Copy link
Contributor

DanySK commented Apr 28, 2021

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 custom version.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 refreshVersions

Running $ ./gradlew refreshVersionsCatalog would

  • Enable catalog version if necessary
// Enable Gradle's version catalog support
// https://docs.gradle.org/current/userguide/platforms.html
enableFeaturePreview("VERSION_CATALOGS")
  • Generate versions.properties, with all version keys (marked as unused)
  • Generate gradle/libs.dependencies.toml
  • Use the IDE and auto-completion to replace hardcoded dependencies with refreshVerion's dependency notations and versionCatalog or buildSrc/Libs.kt
  • To help with this, this task will show which typesafe accessors are available $ ./ gradlew refreshVersionsMapping
androidx.car:car                             | AndroidX.car
com.retrofit:retrofit-converter-json          | Square.retrofit.converter.json
org.koin:koin                                  |  libs.koin

Documentation

@LouisCAD
Copy link
Member

LouisCAD commented May 2, 2021

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".

@jmfayard
Copy link
Member

I have a plan to combine versions catalog and refreshVersions. I updated the issue with my notes

@jmfayard jmfayard changed the title Add support for Gradle 7+ centralized declaration of dependencies Add support for Gradle 7+ Version Catalogs May 19, 2021
@LouisCAD
Copy link
Member

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.

@LouisCAD LouisCAD changed the title Add support for Gradle 7+ Version Catalogs Add support for Gradle 7.4 Version Catalogs Feb 20, 2022
@jmfayard
Copy link
Member

I've got news! cc @DanySK @beski @JSSchneider @NikkyAI and all.

I implemented support for versions catalog:

  • generating it automatically
  • rewriting the files build.gradle(.kts) to use them
  • adding dependency updates in gradle/libs.versions.toml

It's published in the snapshot version "0.40.2-SNAPSHOT"

Have a look at the Testing? pargraph from the pull-request #509

@NikkyAI
Copy link
Collaborator

NikkyAI commented Feb 26, 2022

it would be really nice if this could make use of the extraArtifactVersionKeyRules to group things together
and keep versions in the [versions] section of the toml file

especially versions like kotlin version repeat a lot

for example with this rule (and the builtin rules for kotlin):

com.kotlindiscord.kord.extensions:*
                  ^^^^^^^^^^^^^^^

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)
it should also reduce the load of having to parse that cluttered toml file if one only has to pay attention to the first few lines and the rest is managed..

@jmfayard
Copy link
Member

@NikkyAI that's a very good point, I added it to my tasks lit #509

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants