metals doesn't detect `./gradlew` script in a project with multiple build tools
gersonsosa opened this issue · comments
Describe the bug
my project uses gradle 7.6.x and it requires "verification-metadata"
by looking at the code here
I see a specific version of gradle-bloop is used which results in the gradlew bloopInstall command failing if the verification metadata is not present
the issue happens because the "./gradlew" script is not detected by metals on startup and it attempts to use an embedded one, since the embedded one is based on gradle version 7.5 the gradle-bloop dependency is different than the one in my project (https://repo1.maven.org/maven2/ch/epfl/scala/gradle-bloop_2.13/1.6.1/)
I don't see any alternative to fix this rather than passing a custom script in the startup command but that seems unnecessary considering metals attempts to detect it here
Expected behavior
Metals detects my gradlew wrapper and use it with the version of bloop already installed
Operating system
MacOS
Editor/Extension
Neovim/nvim-metals
Version of Metals
v1.3.0
Extra context or search terms
gradle, build tools, gradle-bloop
@gersonsosa Hi. I've not used verification-metadata before but I'm just trying to understand your setup.
Metals should detect the gradlew file in your workspace dir and use that Gradle wrapper version if it exists. Is it present? And if so - is it a file or is it a symbolic link?
If you don't have a gradlew file in your workspace, do you then have Gradle 7.6 installed globally and on your system path? If so - you can specify that Gradle version by adding "metals.gradleScript": "/path/to/gradle" in the settings (if you're using VSCode).
I can't see you getting round the metadata verification without generating the metadata for ch.epfl.scala:gradle-bloop_2.12:1.6.1. There's no option to specify a version of the plugin other than the latest but the plugin isn't updated that often so it shouldn't be too much work.
Hi @Arthurm1
use that Gradle wrapper version if it exists. Is it present? And if so - is it a file or is it a symbolic link?
it exists, when I pass the parameter gradleScript as "./gradlew" it executes without a problem
I'm not sure how to debug the detection of the file seems like something is wrong there
There's no option to specify a version of the plugin other than the latest but the plugin isn't updated that often so it shouldn't be too much work.
I manually added the verification metadata and it seems to work now, it would be awesome if based on the build tool you could get the current dependency version before attempting to use that one since there are technically two versions here the scala 2.12 (if I understand correctly) and the gradle bloop 1.6.1
it exists, when I pass the parameter gradleScript as "./gradlew" it executes without a problem
Sorry - I don't have a mac so can't diagnose or test to see why AbsolutePath#isFile would possibly fail to detect gradlew in the workspace folder.
I manually added the verification metadata and it seems to work now, it would be awesome if based on the build tool you could get the current dependency version before attempting to use that one since there are technically two versions here the scala 2.12 (if I understand correctly) and the gradle bloop 1.6.1
It's likely only the 1.6.1 part will ever change and not the 2.12 part, i.e. ch.epfl.scala:gradle-bloop_2.12:+
It does seem we are looking for gradlew in the workspace root where we should be looking for it in the project root. Do those things differ in your setup @gersonsosa? Meaning is gradlew exactly at the top level of your workspace/workspace folder?
It's likely only the 1.6.1 part will ever change and not the 2.12 part, i.e. ch.epfl.scala:gradle-bloop_2.12:+
That's good to know, so this version should also work if my project uses scala 2.13.x?
Meaning is gradlew exactly at the top level of your workspace/workspace folder?
It seems that's the case, I have a particular setup because there are multiple levels of directories with "build.gradle.kts" files which might be detected as the root but as far as I see the root directory is being detected correctly
I'll try to debug in my local if that's helpful but I'd love some guidance as how to do it with a flag or if I should put some debug lines in the code.
That's good to know, so this version should also work if my project uses scala 2.13.x?
The plugin version is completely separate from whatever version of scala your project is using
@gersonsosa you can check if #6428 helps with your issue.
@kasiaMarek a delayed response here, yes it works now perhaps I had an old version of metals and updating fixed it! thanks