Open jmfayard opened 1 year ago
After a bit of research, it's a bit tricky because Gradle doesn't give access to the file locations through a public API. We could probably use reflection for that, but it can break on future Gradle versions.
An alternative (which can potentially co-exist with the previous one if we detect breakages of the reflection approach at runtime to let the user know), would be to provide an API for settings to use in place of the default files
function. For example, we can provide an overload or another function that tracks the file. We can also wrap the call to files. We'll see.
It would be really nice to have this, or at least a first shot where you can configure the version catalog files manually.
Or maybe an option to also consider the default version catalog of the root build (not root project, root build).
I have a project consisting of three builds.
Build A
is the top-level build, that includes build B
which includes build C
.
I want all versions centralized in the default version catalog of A
.
But when applying refreshVersions
also to B
and C
, the catalog is not updated, as it is not the default one for those builds.
At the same time, it would be necessary to not remove version update comments.
Because if you then run multiple refreshVersions
tasks on the same file, you only get the version comments for the last one.
I tried to work-around this by copying around the file before and after task execution, but that does not allow to combine the comments from the different tasks.
Here what halfway works as work-around for my use-case:
gradle.rootProject {
tasks.configureEach {
if (name == "refreshVersions") {
doFirst {
copy {
from(gradle.parent!!.rootProject.file("gradle/libs.versions.toml"))
into("gradle")
}
}
doLast {
copy {
from("gradle/libs.versions.toml")
into(gradle.parent!!.rootProject.file("gradle"))
}
delete("gradle")
}
}
}
}
TK @LouisCAD