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
The refreshVersionsCleanup task cleans up different files than the refreshVersions task changed.
For example it uses hard-coded File("gradle/libs.versions.toml") (just with the path from a constant) to clean up the version catalog file.
But using the File constructor in Gradle logic is at best flaky, as is in almost any JVM program.
The File constructor resolves relative paths relative to the current working directory.
In a Gradle run this often is the root project directory, but this is not guaranteed and not always the case.
It could also be the IDE installation directory, or the daemon log directory, ....
The only case I'm aware of where File constructor with a relative path is a good idea is, when developing a commandline utility where the relative path is coming from a commandline argument as there you can usually safely assume that the path is menat realtive to the current working directory.
In my case I'm developing a custom convention plugin that also integrates this plugin.
I added a functional test for refreshVersionsCleanup as I'm doing some tidying to work-around #661 and #663.
Unfortunately, this then "cleaned up" the libs.versions.toml of the plugin project, not the one of the functional test SUT project as the current working directory obviously is not the one of the functional test SUT project.
Unfortunately, this is also not configurable on the refreshVersionsCleanup task, so there is no way to work-around this bug besides avoiding to use the task or disabling it to be on the safe side.
Other similar problematic places currently I have seen are:
Releasing.main.kts where you should use __FILE__.parentFile instead of File(".")
probably VersionsCatalogUpdaterTest#rulesDir
probably TestUtilsKt#testResources
probably ResourcesKt#testResources
probably ResourcesKt#mainResources
probably MigrationTest#Search for files that may contain dependency notations#expected
probably MigrationTest#testResources
probably ResourcesKt#mainResources
probably PluginsVersionKt#pluginsVersion
probably DependencyNotationsWebpageUpdateTest#update the list of dependency notations on the website#destination
The text was updated successfully, but these errors were encountered:
The
refreshVersionsCleanup
task cleans up different files than therefreshVersions
task changed.For example it uses hard-coded
File("gradle/libs.versions.toml")
(just with the path from a constant) to clean up the version catalog file.But using the
File
constructor in Gradle logic is at best flaky, as is in almost any JVM program.The
File
constructor resolves relative paths relative to the current working directory.In a Gradle run this often is the root project directory, but this is not guaranteed and not always the case.
It could also be the IDE installation directory, or the daemon log directory, ....
The only case I'm aware of where
File
constructor with a relative path is a good idea is, when developing a commandline utility where the relative path is coming from a commandline argument as there you can usually safely assume that the path is menat realtive to the current working directory.In my case I'm developing a custom convention plugin that also integrates this plugin.
I added a functional test for
refreshVersionsCleanup
as I'm doing some tidying to work-around #661 and #663.Unfortunately, this then "cleaned up" the
libs.versions.toml
of the plugin project, not the one of the functional test SUT project as the current working directory obviously is not the one of the functional test SUT project.Unfortunately, this is also not configurable on the
refreshVersionsCleanup
task, so there is no way to work-around this bug besides avoiding to use the task or disabling it to be on the safe side.Other similar problematic places currently I have seen are:
Releasing.main.kts
where you should use__FILE__.parentFile
instead ofFile(".")
VersionsCatalogUpdaterTest#rulesDir
TestUtilsKt#testResources
ResourcesKt#testResources
ResourcesKt#mainResources
MigrationTest#Search for files that may contain dependency notations#expected
MigrationTest#testResources
ResourcesKt#mainResources
PluginsVersionKt#pluginsVersion
DependencyNotationsWebpageUpdateTest#update the list of dependency notations on the website#destination
The text was updated successfully, but these errors were encountered: