Gradle should respect system setup

[ItachiSan]

The background Gradle daemon run for supporting Gradle projects doesn't respect system settings.

Environment

• Operating System: ArchLinux, Windows
• JDK version: 8.0.121-b13
• Visual Studio Code version: 1.12.2
• Java extension version: 0.5.0

Steps To Reproduce

1. Open VSCode
2. Open a Gradle-based Java project

Current Result

You can find a running Gradle instance in such a way

$ pgrep -f -a gradle
22406 /usr/lib/jvm/java-8-openjdk/bin/java -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=UTF-8 -Duser.country=IT -Duser.language=it -Duser.variant -cp /user/home/.gradle/wrapper/dists/gradle-3.5-bin/daoimhu7k5rlo48ntmxw2ok3e/gradle-3.5/lib/gradle-launcher-3.5.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 3.5

Expected Result

1. If available, system Gradle should be run
2. Gradle should respect defined variables

Additional Informations

The Gradle options I would like to be respected are these ones:
export GRADLE_OPTS="-Xmx64m -Dorg.gradle.jvmargs='-Xmx256m -XX:MaxPermSize=64m'"
Running Gradle from a terminal does respect them.

[fbricon]

Does your project contain a Gradle wrapper?

[ItachiSan]

Nope, I supposed that was it at first, but I removed it.

> ls


    Directory: E:\Progetti\UniMi\Coding\distributed_systems


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
da----       25/05/2017     17:51                .gradle
da----       19/05/2017     20:58                .settings
... my source folders ...
-a----       19/05/2017     20:58            713 .classpath
-a----       19/05/2017     20:58             96 .gitignore
-a----       19/05/2017     20:58            493 .project
-a----       23/05/2017     21:46            260 build.gradle
-a----       23/05/2017     21:46             45 gradle.properties
-a----       23/05/2017     21:46            330 gretty.plugin
-a----       23/05/2017     21:46            244 README.md
-a----       23/05/2017     21:46            665 settings.gradle

Does anyhow this plugin run a Gradle instance to have Gradle support?

[ItachiSan]

I've got the phantom Gradle also on Windows (output from gwmi Win32_Process -Filter "Name = 'java.exe'" | clip in PowerShell):

...
CommandLine                : E:\Programmi\Java\jdk\bin\java.exe -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Xmx1024m -Dfile.encoding=windows-1252 -Duser.country=IT 
                             -Duser.language=it -Duser.variant -cp C:\Users\Giovanni\.gradle\wrapper\dists\gradle-3.4-bin\aeufj4znodijbvwfbsq3044r0\gradle-3.4\lib\gradle-launcher-3.4.jar 
                             org.gradle.launcher.daemon.bootstrap.GradleDaemon 3.4
...

[fbricon]

so what happens is, if no wrapper is found, then we let BuildShip use whichever default version of Gradle it has defined.

I reckon we could do

1. use gradle wrapper if it exists, else
2. use gradle runtime if found on the system, else
3. use default buildship gradle runtime

For .2, is it enough to check for the GRADLE_HOME env var?

[ItachiSan]

For n. 2 I suppose the best would be to check

1. if GRADLE_HOME exists, then if GRADLE_HOME\bin\gradle exists
2. if gradle exists in PATH and that the setup is good (exempli gratia gradle --version)
   If you've better suggestions, go ahead 😄

[mikegleasonjr]

@ItachiSan @fbricon How do you guys specify GRADLE_HOME to VS Code on OS X?

I have a valid installation in /usr/local/gradle/ (4.2.1) but VS Code uses an old version (3.5) in ~/.gradle/...

I need to specify a recent version because of a syntax error in my build.gradle file with 3.5.

Thanks!

[rubin55]

I ran into the same issue. Having gradle available on the path and/or setting GRADLE_HOME does not make vscode use anything other than gradle-3.5 that comes with buildship (I think).

Note that as a workaround, having a gradle wrapper in your project does make vscode use the gradle version of choice (that the wrapper is).

@fbricon I think this issue needs to be revisited.

[fbricon]

This is supposed to work https://github.com/eclipse/eclipse.jdt.ls/blob/a617c5a630d01ae35b01bdaa29fa7725bc1a45d9/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/managers/GradleProjectImporter.java#L89 :-)

Anyone having the issue on Windows/Linux or is this just a Mac problem?

[fbricon]

@mikegleasonjr @rubin55 see https://apple.stackexchange.com/questions/106355/setting-the-system-wide-path-environment-variable-in-mavericks

if code is opened from CLI, I expect it'd inherit the environment variables available in the terminal.

[rubin55]

I've checked on Windows; if i start a terminal within vscode and do set | findstr GRADLE_HOME, i see it set correctly. Regardless, vscode ignores it as I can tell from the .log file where I see BuildShip trying to parse my incompatible with 3.x build.gradle using Gradle 3.5 instead of the 4.2 I have on my path and referenced in GRADLE_HOME.

[snjeza]

@rubin55 See eclipse-jdtls/eclipse.jdt.ls#408 (comment)

[rubin55]

I am aware of the workaround (I personally opted for using the wrapper). Still I think code should check PATH first and handle this more intuitively, as in:

1. has wrapper? use wrapper
2. has GRADLE_HOME? use that
3. has gradle on path? use that
4. fallback on version in buildship

In that order.

[snjeza]

@rubin55
Buildship requires a gradle distribution. I'm not sure if we can implement #3.
#1, #2 and #4 should work after applying eclipse-jdtls/eclipse.jdt.ls#411

[fbricon]

@rubin55 we could indeed parse the $PATH environment variable to find the gradle executable, but I'm assuming you'd find it only when $PATH has been set when starting a terminal. So if you don't find $GRADLE_HOME, you won't find gradle in $PATH either.

What eclipse-jdtls/eclipse.jdt.ls#411 does is check if the server has been started with a -DGRADLE_HOME parameter, so you need to add it to the java.jdt.ls.vmargs prefs.

[snjeza]

Fixed within #383