Missing customization of GRADLE_USER_HOME #243

hannah23280 · 2020-03-30T07:21:11Z

Extension Name: vscode-gradle
Extension Version: v2.4.13
OS Version: windows 10
VSCode version: v1.43.2

May i know if there is any way to configure GRADLE_USER_HOME for this vscode-gradle extension to recognize? This extension seem to be missing the customization for this variable.

Note that I avoid setting this in my machine's environment variables, and would prefer to do it in the vscode instead. I have also installed vscode-java extension pack, and has configured java.import.gradle.user.home, but sadly no effect for vscode-gradle. This is not surprising as this setting is pertaining to the vscode-java extension , not vscode-gradle extension.

badsyntax · 2020-03-30T07:31:20Z

Thanks for the suggestion. Yep I will do this (when I've got some time).

hannah23280 · 2020-03-31T07:03:53Z

Hi,

Just to report. We can configure environment variables for the vscode terminal via the workspace-level settings. See below
When running gradle task via vscode-gradle extension, I think this extension runs in the context of the terminal, so it uses whatever environment variables defined in the settings.

"settings": {
"terminal.integrated.env.windows": {
"PATH": "${env:Path} ; D:/Software/java/jdk1.8.0_77/bin",
"GRADLE_USER_HOME": "${workspaceFolder}/.gradle",
"JAVA_HOME": "D:/Software/java/jdk1.8.0_77"
},

badsyntax · 2020-03-31T07:30:04Z

Great, yes this should work. Thanks for this tip. I'll add this info to the README.

hannah23280 · 2020-03-31T08:18:43Z

okie.

badsyntax · 2020-03-31T13:13:43Z

Am re-opening just to to remind myself to update the README when I get some time

hannah23280 · 2020-04-21T10:36:05Z

Hi, just to feedback.

VS Code: v1.44.2
Extension Version: v2.5.1 (latest version)

The solution i highglighted in previous thread seems not working anymore.
"settings": {
"terminal.integrated.env.windows": {
"PATH": "${env:Path} ; D:/Software/java/jdk1.8.0_77/bin",
"GRADLE_USER_HOME": "${workspaceFolder}/.gradle",
"JAVA_HOME": "D:/Software/java/jdk1.8.0_77"
},

When the GRADLE_USER_HOME is as shown above, the GRADLE TASKS pane in vscode is empty.
But when i set its value to the full path, instead of using the variable ${workspaceFolder}, the pane displays the gradle tasks.

Can i confirm whether the vscode-gradle extension support variable set in the settings.json?

Side note: Is this file org.eclipse.buildship.core.prefs generated by vscode-gradle extension?

hannah23280 · 2020-04-21T10:41:13Z

in addition,
i notice that the vscode-gradle is able to support java.home (contributed by vscode-java). Can it also support java.import.gradle.user.home (contributed also by vscode-java) ?

badsyntax · 2020-04-21T11:25:52Z

Hi, thanks for letting me know. I'll have a look.

Side note: Is this file org.eclipse.buildship.core.prefs generated by vscode-gradle extension?

Not, I believe this is generated by the Java Language support extension, as it uses the eclipse language server which in turn uses buildship.

i notice that the vscode-gradle is able to support java.home (contributed by vscode-java). > Can it also support java.import.gradle.user.home (contributed also by vscode-java) ?

I will consider to do this.

hannah23280 · 2020-04-25T03:00:49Z

Hi,
In case u are not aware, i had saw one post in the vscode forum, regarding the api that can help to automatically resolve any variable used in the setting.

"In VS Code 1.42 we will introduce a new hook resolveDebugConfigurationWithSubstitutedVariables in the extension API that receives the debug configuration with all variables resolved."

Not sure if this will help in case in future, u might want to consider supporting variable expansion in the settings.

badsyntax · 2020-04-28T17:21:11Z

I've tested this in MacOS and Windows and the variable substitution works as expected. I had to accept the following:

Did you see any errors in the "Gradle Tasks" output?

badsyntax · 2020-04-28T17:45:43Z

I will however add support for java.import.gradle.user.home to provide integrations between the gradle and java extensions.

hannah23280 · 2020-04-28T18:09:49Z

I've tested this in MacOS and Windows and the variable substitution works as expected. I had to accept the following:

Did you see any errors in the "Gradle Tasks" output?

Oops...sorrie. i came to realize it is my fault. There is a space after the double quote and before the ${workspaceFolder} in my file, and i dont realize that earlier until now. The sample i give above does not have space cos i manually type it. Should I do copy and paste from the actual file, the space would be there.
Removing the space solve the issue.

hannah23280 · 2020-04-28T18:10:38Z

I will however add support for java.import.gradle.user.home to provide integrations between the gradle and java extensions.

great to hear that. Thanks!

badsyntax · 2020-04-29T09:06:27Z

@hanct do you know if java.import.gradle.user.home supports relative paths in the Java language support extension? It seems like the setting is ignored if not using an absolute path. Can you confirm?

badsyntax · 2020-04-29T09:18:34Z

Actually it does seem to support relative paths, eg:

"java.import.gradle.user.home": "test-gradle-home"

badsyntax · 2020-04-29T11:31:29Z

Actually, it doesn't look like relative paths are supported, i'm getting the following error:

The Language support extension downloads the wrapper correctly into the correct (relative) path but then bombs out with the error above. No problems with absolute path.

badsyntax · 2020-04-29T11:50:35Z

When setting an absolute path, and clearing the custom gradle user home directory, there's a conflict between gradle tasks and language server extensions as they both try to install the gradle executable. This error is thrown by the language server:

org.gradle.tooling.GradleConnectionException: Could not install Gradle distribution from 'https://services.gradle.org/distributions/gradle-6.3-bin.zip'.
	at org.gradle.tooling.internal.consumer.DistributionFactory$ZippedDistribution.getToolingImplementationClasspath(DistributionFactory.java:139)
	at org.gradle.tooling.internal.consumer.loader.CachingToolingImplementationLoader.create(CachingToolingImplementationLoader.java:41)
	at org.gradle.tooling.internal.consumer.loader.SynchronizedToolingImplementationLoader.create(SynchronizedToolingImplementationLoader.java:44)
	at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.onStartAction(LazyConsumerActionExecutor.java:104)
	at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:86)
	at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45)
	at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:61)
	at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38)
	at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor.lambda$run$0(DefaultAsyncConsumerActionExecutor.java:55)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
	at java.base/java.lang.Thread.run(Thread.java:835)
	at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
	at org.gradle.tooling.internal.consumer.DefaultModelBuilder.get(DefaultModelBuilder.java:51)
	at org.gradle.tooling.internal.consumer.DefaultProjectConnection.getModel(DefaultProjectConnection.java:50)
	at org.eclipse.buildship.core.internal.util.gradle.CompatProjectConnection.getModel(CompatProjectConnection.java:53)
	at org.eclipse.buildship.core.internal.util.gradle.IdeAttachedProjectConnection.configureOperation(IdeAttachedProjectConnection.java:68)
	at org.eclipse.buildship.core.internal.util.gradle.IdeAttachedProjectConnection.model(IdeAttachedProjectConnection.java:59)
	at org.eclipse.buildship.core.internal.CachingProjectConnection.model(CachingProjectConnection.java:59)
	at org.eclipse.buildship.core.internal.CachingProjectConnection.getModel(CachingProjectConnection.java:39)
	at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runTasksAndQueryModels(EclipseModelUtils.java:56)
	at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$null$4(DefaultModelProvider.java:75)
	at org.eclipse.buildship.core.internal.DefaultGradleBuild$GradleConnectionOperation.runInToolingApi(DefaultGradleBuild.java:329)
	at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317)
	at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39)
	at org.eclipse.buildship.core.internal.DefaultGradleBuild.withConnection(DefaultGradleBuild.java:122)
	at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$fetchEclipseProjectAndRunSyncTasks$5(DefaultModelProvider.java:75)
	at com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4878)
	at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3529)
	at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278)
	at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2155)
	at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045)
	at com.google.common.cache.LocalCache.get(LocalCache.java:3953)
	at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4873)
	at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.getFromCache(DefaultModelProvider.java:98)
	at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.executeOperation(DefaultModelProvider.java:90)
	at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.fetchEclipseProjectAndRunSyncTasks(DefaultModelProvider.java:72)
	at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.runInToolingApi(DefaultGradleBuild.java:226)
	at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager$WorkspaceRunnableAdapter.run(DefaultToolingApiOperationManager.java:58)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2292)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317)
	at org.eclipse.buildship.core.internal.operation.DefaultToolingApiOperationManager.run(DefaultToolingApiOperationManager.java:39)
	at org.eclipse.buildship.core.internal.DefaultGradleBuild$SynchronizeOperation.run(DefaultGradleBuild.java:192)
	at org.eclipse.buildship.core.internal.DefaultGradleBuild.synchronize(DefaultGradleBuild.java:100)
	at org.eclipse.buildship.core.internal.DefaultGradleBuild.synchronize(DefaultGradleBuild.java:86)
	at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporter.startSynchronization(GradleProjectImporter.java:181)
	at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporter.importDir(GradleProjectImporter.java:103)
	at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporter.lambda$0(GradleProjectImporter.java:95)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
	at java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
	at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporter.importToWorkspace(GradleProjectImporter.java:95)
	at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.importProjects(ProjectsManager.java:104)
	at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.initializeProjects(ProjectsManager.java:94)
	at org.eclipse.jdt.ls.core.internal.handlers.InitHandler$1.runInWorkspace(InitHandler.java:196)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:42)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.RuntimeException: Timeout of 120000 reached waiting for exclusive access to file: /Users/richardwillis/Projects/badsyntax/example-project-simple/test-gradle-home-4/wrapper/dists/gradle-6.3-bin/8tpu6egwsccjzp10c1jckl0rx/gradle-6.3-bin.zip
	at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:65)
	at org.gradle.wrapper.Install.createDist(Install.java:48)
	at org.gradle.tooling.internal.consumer.DistributionInstaller.install(DistributionInstaller.java:72)
	at org.gradle.tooling.internal.consumer.DistributionFactory$ZippedDistribution.getToolingImplementationClasspath(DistributionFactory.java:133)
	at org.gradle.tooling.internal.consumer.loader.CachingToolingImplementationLoader.create(CachingToolingImplementationLoader.java:41)
	at org.gradle.tooling.internal.consumer.loader.SynchronizedToolingImplementationLoader.create(SynchronizedToolingImplementationLoader.java:44)
	at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.onStartAction(LazyConsumerActionExecutor.java:104)
	at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:86)
	at org.gradle.tooling.internal.consumer.connection.CancellableConsumerActionExecutor.run(CancellableConsumerActionExecutor.java:45)
	at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConsumerActionExecutor.run(ProgressLoggingConsumerActionExecutor.java:61)
	at org.gradle.tooling.internal.consumer.connection.RethrowingErrorsConsumerActionExecutor.run(RethrowingErrorsConsumerActionExecutor.java:38)
	at org.gradle.tooling.internal.consumer.async.DefaultAsyncConsumerActionExecutor.lambda$run$0(DefaultAsyncConsumerActionExecutor.java:55)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
	at java.base/java.lang.Thread.run(Thread.java:835)

After the gradle wrapper is correctly downloaded, and the vscode window is restarted, the two extensions work correctly.

This error is unexpected. I expected gradle to correctly handle these competing processes. One possible workaround is to wait for the java language server to be ready before getting build information.

hannah23280 · 2020-04-29T12:22:34Z

@hanct do you know if java.import.gradle.user.home supports relative paths in the Java language support extension? It seems like the setting is ignored if not using an absolute path. Can you confirm?

Hi.
Before I assist to confirm on this, can i first query whats the difference between the

gradle.user.home specified inside the org.eclipse.buildship.core.prefs and
java.import.gradle.user.home inside the vscode settings.json file.

Is it right for me to say that org.eclipse.buildship.core.prefs should NOT be manually modified? In other words, if i update the java.import.gradle.user.home in the settings.json, the vscode-java extension should sync this up to the prefs file?

badsyntax · 2020-04-29T12:34:39Z

I got confused by some of the settings myself.

There's two vscode settings: java.import.gradle.home and java.import.gradle.user.home. It's very easy to miss this.

java.import.gradle.user.home (GRADLE_USER_HOME) is where the gradle wrapper is downloaded and where all project dependencies are downloaded, as well as bunch of other stuff that gradle uses
java.import.gradle.home (GRADLE_HOME) is a little confusing and i don't yet have a good a good understanding of it, but I think it's a path to the gradle binary files. It seems an unreliable setting to use, especially if using the gradle wrapper. Also see: https://docs.gradle.org/current/javadoc/org/gradle/api/invocation/Gradle.html#getGradleHomeDir--

Is it right for me to say that org.eclipse.buildship.core.prefs should NOT be manually modified?

As this is used by the language server, I don't have a very good understanding of the point of this file. Saying that, I have found that this file does not sync correctly with the vscode settings and can cause issues if not synced. To fix, I just delete the .settings directory and restart vscode. The language server will then re-generate that file.

In other words, if i update the java.import.gradle.user.home in the settings.json, the vscode-java extension should sync this up to the prefs file?

IMO it should, but it doesn't always sync this file. As mentioned, delete the .settings dir to regenerate.

badsyntax · 2020-04-29T12:36:26Z

I didn't really answer your main question. From my testing, it seems to me that yes, gradle.user.home specified inside the org.eclipse.buildship.core.prefs should match java.import.gradle.user.home

hannah23280 · 2020-04-29T14:25:36Z

I didn't really answer your main question. From my testing, it seems to me that yes, gradle.user.home specified inside the org.eclipse.buildship.core.prefs should match java.import.gradle.user.home

The funny thing is when i change the value for java.import.gradle.user.home, it does not auto sync up with org.eclipse.buildship.core.prefs. Even restart vscode does not help. Anyway, i will raise this observation in vscode-java forum to understand more about how it works.

badsyntax · 2020-04-29T15:39:24Z

@hanct did you delete the org.eclipse.buildship.core.prefs file before restarting vscode? if you raise this to them can you link it here? thanks

hannah23280 · 2020-04-29T15:59:27Z

@hanct did you delete the org.eclipse.buildship.core.prefs file before restarting vscode? if you raise this to them can you link it here? thanks

Hi. I delete it, then restart vscode. No use. However, i now realize by running "Java: Clean the Java language server workspace”, this command will clean up certain things then restart vscode. Then my prefs file is back again.

hannah23280 · 2020-04-29T16:06:34Z

@hanct do you know if java.import.gradle.user.home supports relative paths in the Java language support extension? It seems like the setting is ignored if not using an absolute path. Can you confirm?

Below is my finding after several round of testing
Conclusion: java.import.gradle.user.home does NOT support relative path and does NOT support variable expansion

Here is my step by step approach:
Step 1) Update to "java.import.gradle.user.home": ".gradle20" \\note that ".\.gradle20" make no difference
Step 2) Run "Java: Clean the Java language server workspace” via the command palette. This will auto restart the vscode
Step 3) Once vscode starts up, it will create .gradle folder in the project folder (which is what I want), but it unable to download libraries and produce the below error

Could not run phased build action using Gradle distribution 'https://services.gradle.org/distributions/gradle-6.3-bin.zip'.
Could not start Gradle daemon.
Cannot convert relative path .gradle20\daemon\6.3 to an absolute file.

Query: Which extension results in the .gradle20 folder created in the project folder? vscode-java or vscode-gradle?

badsyntax · 2020-04-29T16:11:55Z

Thanks, this matches my testing too.

Query: Which extension results in the .gradle20 folder created in the project folder? vscode-java or vscode-gradle?

vscode-java is doing this. It creates the directory, and successfully downloads the gradle binary into that directory, but is unable to execute it and throws that error you're seeing.

The vscode-gradle extension is still using GRADLE_USER_HOME (default is $HOME/.gradle)

hannah23280 · 2020-04-29T16:13:15Z

The only biggest wish i have for vscode-java is that they support variable expansion for java.home and java.import.user.gradle.home. if they can support that, it is as good as using relative path.

redhat-developer/vscode-java#1357 , i have previously raise request to support variable expansion for java.home, but no one seems to reply. Maybe they have difficulty supporting variable expansion,

badsyntax · 2020-04-29T16:53:38Z

It's annoying I agree, but variable expansion in config/settings is a core missing feature in vscode, see: microsoft/vscode#46471 So I would not expect the extension authors to solve this themselves.

Although they could make some reasonable assumptions, as i've done with #314, which is to check if the path is relative, and if so, prepend the absolute workspace folder path. I can understand if they don't want to do this though.

hannah23280 · 2020-04-29T17:35:17Z

It's annoying I agree, but variable expansion in config/settings is a core missing feature in vscode, see: microsoft/vscode#46471 So I would not expect the extension authors to solve this themselves.

Although they could make some reasonable assumptions, as i've done with #314, which is to check if the path is relative, and if so, prepend the absolute workspace folder path. I can understand if they don't want to do this though.

Wau! I like what u have done: " to check if the path is relative, and if so, prepend the absolute workspace folder path".

Have u suggest this method to them as an alternative to variable expansion? I don't see why they will not adopt your method.

hannah23280 · 2020-04-29T17:37:57Z

In fact, they can even create 2 additional settings ;
java.import.gradle.user.home and java.import.gradle.user.home.relative.

The former is for absolute and the latter is for relative. If developer specify both, then the extension can choose one of them to be higher priority. Same for java.home

But of course, if they do this, they will have to do that for each and every settings whose values is path, and they end up having to maintain lots of settings..

badsyntax · 2020-04-29T17:51:28Z

Personally I wold prefer not introducing new settings to accommodate relative/absolute. It's pretty easy to normalise a relative path from node.js so I might suggest this approach to them when I have some time.

Anyways, it's not perfect, but i'm fairly happy with #314 now and will be merging soon. I don't want to release until I've added code to support all the other settings (eg java.import.gradle.jvmArguments etc). I'll let you know when I've released.

hannah23280 · 2020-04-29T18:04:52Z

Noted!
But in order for us user to be able to use the relative path, both parties must agree to accept the approach, since both extensions will be using the same settings.

badsyntax · 2020-05-05T17:14:09Z

Hey, this fix has been released. Can you update to the latest version and give it a test?

hannah23280 · 2020-05-05T17:49:22Z

Sure, but is your fix referring to that we are now able to use java.import.gradle.user.home and using relative path? If yes, but has vscode-java also able to support the relative path also?

Cos if i set the java.import.gradle.user.home to relative path, vscode-gradle can works, but vscode-java will break. I would not be able to run the application.

badsyntax · 2020-05-05T18:03:03Z

They're two separate issues. The fix is to support java.import.gradle.user.home (with absolute path).
I haven't had the time to contribute to the relative paths issue in vscode-java. I'm following this issue though. When I got some time i'll contribute.

badsyntax · 2020-05-05T18:08:13Z

I might have found a fix for #245 and want to get that done first. If it turns out to be a good fix then I'll contribute the same fix for vscode-java

hannah23280 · 2020-05-05T19:10:25Z

Noted.

I have done the test. Yes, it is successful!

For the testing, I remove away the GRADLE_USER_HOME settings which i set in the settings.json. And ensure that the java.import.gradle.user.home is set to absolute path.

Side note:
Btw, i notice that whenever i stop the debugging in the gradle task pane, i notice that the vscode is busy processing something. That processing goes for quite sometime, before it stop.
While it is processing something, i notice my terminal in vscode labelled "Task - Java:Java Build Status (codes)" is showing the below and it seems to be doing some sort of refreshing, and it can take a while before it start displaying other logs...

e2d23231 Importing root project: 20% Refreshing '/codes'. [196/1000]
.
Query: Is the above generated by vscode-gradle, or vscode-java extension?

badsyntax · 2020-05-05T19:27:37Z

Great thank you for testing!

For the side note, yes this process is started by vscode-gradle.

After a task is run, vscode-gradle tells vscode-java to update the java project configuration (see https://github.com/redhat-developer/vscode-java#available-commands) and that's what you're seeing. vscode-java is re-compiling necessary java files and updating the classpath.

The reason why I've done this, is that gradle build tasks could generate new Java files (for example, generating Java classes from protobuf files). In this case, we want vscode-java to recognise the new Java files, compile them, and show the correct references in the editor.

From my testing, usually this is a quick process, as vscode-java has already previously indexed all the Java files (on editor start), and should only compile new Java files.

If this is taking a long time for you, potentially there's an error with vscode-java. In this case, you can open the java logs by running command "Java: Open all log files" and see if there are any exceptions in there.

I can also potentially explore other ways to improve this. I wasn't aware this was causing issues for people.

I'm gonna close this issue now and will work on the relative paths issue as part of #245

zergeborg · 2020-08-03T00:47:18Z

@badsyntax Thanks for this plugin, it looks great. But I tried to set the GRADLE_USER_HOME in the workspace settings.json file and it still fails. Are you sure that this has been fixed?

Here are the vscode details:

Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-23T13:08:29.692Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.4.0

And here is my workspace settings.json content:

{
    "terminal.integrated.env.osx": {
                "GRADLE_USER_HOME":"/whatever",
    },
}

The thing is that this value is actually properly set when I open a new terminal window and I run the env command, but the actual value is empty when I print it from build.gradle like this (my build gradle is written in Kotlin):

println("Env variable:")
println(System.getenv("GRADLE_USER_HOME"))

By the way, I am using zsh with the oh-my-zsh extension, I don't know if that matters or not.

badsyntax · 2020-08-04T08:03:20Z

@zergeborg setting GRADLE_USER_HOME as part of terminal settings within settings.json wont work anymore since i changed how the server is started with #540 - the server is no longer started via an integrated terminal.

At the moment the only way to configure GRADLE_USER_HOME is by either setting the env var, or by setting java.import.gradle.user.home within settings.json. I will re-open this issue to improve the settings.

zergeborg · 2020-08-05T00:08:02Z

@badsyntax Thank you for replying quickly. I see. I was not aware of that change in #540

Thanks for improving it.

hannah23280 added the bug Something isn't working label Mar 30, 2020

hannah23280 assigned badsyntax Mar 30, 2020

badsyntax added enhancement New feature or request and removed bug Something isn't working labels Mar 30, 2020

hannah23280 closed this as completed Mar 31, 2020

badsyntax reopened this Mar 31, 2020

badsyntax mentioned this issue Apr 4, 2020

VSCode java home not being used #249

Closed

badsyntax added the reviewed label Apr 5, 2020

badsyntax mentioned this issue Apr 29, 2020

Add support for custom GRADLE_USER_HOME #314

Merged

badsyntax closed this as completed in #314 Apr 29, 2020

badsyntax reopened this Apr 29, 2020

badsyntax mentioned this issue May 5, 2020

Support relative paths #332

Draft

badsyntax closed this as completed May 5, 2020

badsyntax reopened this Aug 4, 2020

CsCherrYY mentioned this issue Aug 19, 2021

[error] [gradle-server] Gradle version is required #922

Closed

CsCherrYY removed the reviewed label Dec 2, 2021

Missing customization of GRADLE_USER_HOME #243

Missing customization of GRADLE_USER_HOME #243

Comments

hannah23280 commented Mar 30, 2020

badsyntax commented Mar 30, 2020

hannah23280 commented Mar 31, 2020 • edited Loading

badsyntax commented Mar 31, 2020

hannah23280 commented Mar 31, 2020

badsyntax commented Mar 31, 2020

hannah23280 commented Apr 21, 2020 • edited Loading

hannah23280 commented Apr 21, 2020

badsyntax commented Apr 21, 2020

hannah23280 commented Apr 25, 2020 • edited Loading

badsyntax commented Apr 28, 2020

badsyntax commented Apr 28, 2020

hannah23280 commented Apr 28, 2020

hannah23280 commented Apr 28, 2020

badsyntax commented Apr 29, 2020

badsyntax commented Apr 29, 2020

badsyntax commented Apr 29, 2020

badsyntax commented Apr 29, 2020 • edited Loading

hannah23280 commented Apr 29, 2020

badsyntax commented Apr 29, 2020

badsyntax commented Apr 29, 2020

hannah23280 commented Apr 29, 2020 • edited Loading

badsyntax commented Apr 29, 2020

hannah23280 commented Apr 29, 2020 • edited Loading

hannah23280 commented Apr 29, 2020 • edited Loading

badsyntax commented Apr 29, 2020

hannah23280 commented Apr 29, 2020

badsyntax commented Apr 29, 2020

hannah23280 commented Apr 29, 2020

hannah23280 commented Apr 29, 2020 • edited Loading

badsyntax commented Apr 29, 2020

hannah23280 commented Apr 29, 2020

badsyntax commented May 5, 2020

hannah23280 commented May 5, 2020

badsyntax commented May 5, 2020

badsyntax commented May 5, 2020

hannah23280 commented May 5, 2020

badsyntax commented May 5, 2020

zergeborg commented Aug 3, 2020

badsyntax commented Aug 4, 2020

zergeborg commented Aug 5, 2020

hannah23280 commented Mar 31, 2020 •

edited

Loading

hannah23280 commented Apr 21, 2020 •

edited

Loading

hannah23280 commented Apr 25, 2020 •

edited

Loading

badsyntax commented Apr 29, 2020 •

edited

Loading

hannah23280 commented Apr 29, 2020 •

edited

Loading

hannah23280 commented Apr 29, 2020 •

edited

Loading

hannah23280 commented Apr 29, 2020 •

edited

Loading

hannah23280 commented Apr 29, 2020 •

edited

Loading