microsoft
Missing customization of GRADLE_USER_HOME
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.
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" },
Great, yes this should work. Thanks for this tip. I'll add this info to the README.
Am re-opening just to to remind myself to update the README when I get some time
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?
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) ?
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.
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.
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?
I will however add support for java.import.gradle.user.home to provide integrations between the gradle and java extensions.
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.
I will however add support for
java.import.gradle.user.hometo provide integrations between the gradle and java extensions.
great to hear that. Thanks!
@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?
Actually it does seem to support relative paths, eg:
"java.import.gradle.user.home": "test-gradle-home"
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.
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.
@hanct do you know if
java.import.gradle.user.homesupports 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?
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.
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
I didn't really answer your main question. From my testing, it seems to me that yes,
gradle.user.homespecified inside the org.eclipse.buildship.core.prefs should matchjava.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.
@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
@hanct did you delete the
org.eclipse.buildship.core.prefsfile 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.
@hanct do you know if
java.import.gradle.user.homesupports 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?
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)
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.
https://github.com/redhat-developer/vscode-java/issues/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,
It's annoying I agree, but variable expansion in config/settings is a core missing feature in vscode, see: https://github.com/microsoft/vscode/issues/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 https://github.com/badsyntax/vscode-gradle/pull/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.
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.
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..
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 https://github.com/badsyntax/vscode-gradle/pull/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.