metals doesn't detect ./gradlew script in a project with multiple build tools

[gersonsosa]

Describe the bug

my project uses gradle 7.6.x and it requires "verification-metadata"

by looking at the code here

metals/metals/src/main/scala/scala/meta/internal/builds/GradleBuildTool.scala

Lines 24 to 37 in ba7763e

	private val gradleBloopVersion = BuildInfo.gradleBloopVersion
	private def initScript = {
	s"""
	|initscript {
	|${GradleBuildTool.toGradleRepositories(Repository.defaults.asScala.toList)}
	| dependencies {
	| classpath 'ch.epfl.scala:gradle-bloop_2.12:$gradleBloopVersion'
	| }
	|}
	|allprojects {
	| apply plugin: bloop.integrations.gradle.BloopPlugin
	|}
	""".stripMargin.getBytes()
	}

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/)

metals/metals/src/main/scala/scala/meta/internal/builds/GradleBuildTool.scala

Lines 92 to 98 in ba7763e

	case None =>
	val workspaceGradle = workspaceGradleLauncher(workspace)
	if (workspaceGradle.isFile)
	workspaceGradle.toString() :: cmd
	else
	embeddedGradleLauncher.toString() :: cmd
	}

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

metals/metals/src/main/scala/scala/meta/internal/builds/GradleBuildTool.scala

Lines 93 to 95 in ba7763e

	val workspaceGradle = workspaceGradleLauncher(workspace)
	if (workspaceGradle.isFile)
	workspaceGradle.toString() :: cmd

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

[Arthurm1]

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

[gersonsosa]

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

[Arthurm1]

@gersonsosa

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:+

[kasiaMarek]

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?

[gersonsosa]

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.

[Arthurm1]

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

[kasiaMarek]

@gersonsosa you can check if #6428 helps with your issue.