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
Is your feature request related to a problem?
Currently, dependency versions are being declared on respective build.gradle file module with Groovy DSL.
This scattered approach complicates maintenance, increase the risk of inconsistencies, and make it challenging to manage and update dependencies across the SQL project.
Let's take Junit as an example:
Which both versions .4.13.2 and 5.9.3 are being declared within the project, and because of this, test-cases syntax are being diverted accordingly throughout the project.
What solution would you like?
To have a two-phases approach to eventually migrate all the versions declaration from the current form, to Gradle version catalog, which includes:
Phase-1: Centralise all version declaration in the form of Gradle property
Phase-2: Migrate Gradle properties into a standalone libs.versions.toml file.
What alternatives have you considered?
A Gradle version catalog is not suitable in this SQL project, then we should at-least centralise all version declaration into parent module, as a custom configuration file.
Is your feature request related to a problem?
Currently, dependency versions are being declared on respective
build.gradle
file module with Groovy DSL.This scattered approach complicates maintenance, increase the risk of inconsistencies, and make it challenging to manage and update dependencies across the SQL project.
Let's take Junit as an example:
Which both versions
.4.13.2
and5.9.3
are being declared within the project, and because of this, test-cases syntax are being diverted accordingly throughout the project.What solution would you like?
To have a two-phases approach to eventually migrate all the versions declaration from the current form, to Gradle version catalog, which includes:
libs.versions.toml
file.What alternatives have you considered?
A Gradle version catalog is not suitable in this SQL project, then we should at-least centralise all version declaration into parent module, as a custom configuration file.
Do you have any additional context?
Gradle site reference for version catalogs: https://docs.gradle.org/current/userguide/version_catalogs.html?utm_source=chatgpt.com
PR placeholder:
The text was updated successfully, but these errors were encountered: