Project cannot be synced when gradle init script path contains white spaces

Good evening vscode-java team! Hope all is well.
When I set generatesMetadataFilesAtProjectRoot to true and refresh the project, org.eclipse.buildship.core.prefs gets updated to include arguments=--init-script /Users/[...me]/Library/Application Support/Code - Insiders/User/globalStorage/redhat.java[...], etc. These scripts seem to be injecting some plugins and doing some setup stuff, which is totally cool, and things seem okay until the next time I rebuild (like by editing+saving the gradle file).

Due to the spaces in the path, the first one being in Application Support, I get an error:
[Error - 7:15:04 PM] Sep 24, 2022, 7:15:04 PM Error occured while building workspace. Details: message: Could not run phased build action using connection to Gradle distribution '[...]/gradle-7.5.1-bin.zip'. The specified initialization script '/Users/[...me]/Library/Application' does not exist.; code: 0; resource: /Users/[...me]/Documents/[...project-path]/build.gradle;

I am able to work around this issue by either:

removing the arguments line temporarily, re-saving the build.gradle file, and watch as it builds successfully.
a bit more severe, but by using the --user-data-dir /Users/[...me]/.vscode-insiders/user-data flag applied to VS Code itself, the path that gets set for arguments is now a valid one!

Notes:

I tried every combination of quotes, escape characters, etc to get [...]/Application Support[...] to work and nothing would fix it. It just would not allow a path with a space in it.
I didn't try it, but maybe another work around could be a settings/option to turn on that has it instead use a local (to the .settings folder) init gradle script that calls those other init scripts within it.
(user directory name redacted in all references to [...me])

Environment

Operating System: MacOS 12.6
JDK version: 17.0.3
Visual Studio Code version: 1.72.0-insider
Java extension version: v1.11.2022092404

Steps To Reproduce

Be on a mac
Turn on thegeneratesMetadataFilesAtProjectRoot setting.
Refresh the project, and watch as the org.eclipse.buildship.core.prefs file gets the described arguments line.
Try to save the build.gradle file (automatic updating is turned on), and see it fail.

You may use https://spring.io/guides/gs/gradle/ w/ the "complete" project as a base hello world project. It just needs a gradle update to 7.3.X, which you all nicely tell us to do/help us through on open.

log.txt

Current Result

Project won't build on build.gradle save due to inappropriate init scripts locations (no quotes around a spaced location)

Expected Result

Project builds under those circumstances.

Additional Informations

Provided upon request.

@CsCherrYY

I think it's not because of the generatesMetadataFilesAtProjectRoot property, but caused by using URI related APIs when we deal with the path with spaces.

Anyway, @CsCherrYY is now working on it.

A related commit: eclipse-jdtls/eclipse.jdt.ls@3d1a42c#diff-4be4f273e609fde1220c2d89f532f1fe207f280c100126555c3747fcf44d18d8L604

@tthornton3-chwy

So is this a duplicate of eclipse-jdtls/eclipse.jdt.ls#2222 ? Error looks different but whitespace in the path was exactly the issue in that one. If so, let's just mark this as a duplicate of that and close, because it will be in the next release.

@tthornton3-chwy , if you try a vscode-java pre-release version, does it solve the issue ?

@rgrunber

@rgrunber unfortunately no, I am currently on the pre-release version (v1.11.2022092604), did a refresh project, etc and still see this same error when saving the build.gradle file (with java.configuration.updateBuildConfiguration set to automatic). I also tried building latest eclipse.jdt.ls above from source, and manually replacing it in the project, and still getting that error. Is there something else you'd like me to try?

@rgrunber

@rgrunber The issue can't be reproduced in VS Code 1.10.0 but can in the master and pre-release version.
It is introduced by eclipse-jdtls/eclipse.jdt.ls@3d1a42c#diff-4be4f273e609fde1220c2d89f532f1fe207f280c100126555c3747fcf44d18d8L604

@rgrunber

It's a buildship bug, see: eclipse-buildship/buildship#1207. @rgrunber Maybe we have to temporary copy the init scripts to system temp folder in case of the path containing spaces?

@snjeza

That might be a possible workaround (since often, the tempdir path doesn't contain spaces). I tried intentionally placing a space on the path to the init script on Linux and it seemed to work for me. Might this be Windows / MacOS specific ? Also how does this line up with @snjeza's mention of it working on in the release but not in the pre-release ?

@snjeza

I tried intentionally placing a space on the path to the init script on Linux and it seemed to work for me. Might this be Windows / MacOS specific ?

maybe, you can just follow the steps I just pasted in the buildship issue to see if we can reproduce it in Linux systems. It might help Gradle guys find the root cause of this problem, note: directly editing global settings works well, editing project specific settings in eclipse might encounter this issue.

Also how does this line up with @snjeza's mention of it working on in the release but not in the pre-release ?

Yes, I can confirm that in the last release version (1.10.0), the extension have errors mentioned in #2222 in logs, but not in problems panel, while in the pre-release version if classpath updated, the error in this issue will shown in the problems panel.

Both of the two versions can import the project successfully, but seems to have issues updating classpath for affected projects (Android and protobuf)

Copy to the temp folder might have another problem, it will generate a lot of init scripts in the temp folder. At least on Windows, the File.deleteOnExit() is not working for some reason. I suspect it's because the JVM is not shut down normally.

Well, I just sort out the story.

1.10.0

#2222 shows some errors caused by spaces in URIs. These errors will not affect the import & synchorize process since we have a fallback mechanism, see: https://github.com/eclipse/eclipse.jdt.ls/blob/1058840b2e442486ddd7e7d117db9e2db7533a32/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/managers/GradleProjectImporter.java#L599-L617

when fileURL.toURI() fails due to spaces in the URI string, we fallback to getGradleInitScriptTempFile() and create the init script file in system temporary folder and continue the import & synchorize process. So you can find errors in server log, but it works.

1.11.2022092604

#2234 fixes #2222 and sends correct arguments to buildship BuildConfiguration, however, eclipse-buildship/buildship#1207 makes it fail to synchorize the project. So you can find error shows the init script path is splited by spaces.

Solution

I suggested to follow the previous fallback mechanism and do not send arguments within spaces to buildship until eclipse-buildship/buildship#1207 got solved. I will create a PR later.

@jdneo

Copy to the temp folder might have another problem, it will generate a lot of init scripts in the temp folder. At least on Windows, the File.deleteOnExit() is not working for some reason. I suspect it's because the JVM is not shut down normally.

@jdneo See #880

@snjeza

FWIW, I'm able to reproduce. It's just that the failures are hidden in the logs :

(script path was gradle/in it/init.gradle)

Caused by: java.lang.IllegalArgumentException: The specified initialization script '/home/rgrunber/git/vscode-java/server/config_linux/org.eclipse.osgi/51/0/.cp/gradle/in' does not exist.

I've merged the suggested workaround, but can someone test @snjeza's proposal for fixing things on Windows, regarding the init scripts not being removed ?

@snjeza

but can someone test @snjeza's proposal for fixing things on Windows, regarding the init scripts not being removed?

I'll do it.

hi, i reported the #2700 issue which has been closed,but it still have exception when upgrading to v1.11.2022092704 on macos，following log：

.......
he supplied phased action failed with an exception.
org.gradle.tooling.BuildActionFailureException: The supplied phased action failed with an exception.
	at org.gradle.tooling.internal.consumer.connection.PhasedActionAwareConsumerConnection.run(PhasedActionAwareConsumerConnection.java:58)
	at org.gradle.tooling.internal.consumer.connection.ParameterValidatingConsumerConnection.run(ParameterValidatingConsumerConnection.java:62)
	at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter$1.run(DefaultPhasedBuildActionExecuter.java:78)
	at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter$1.run(DefaultPhasedBuildActionExecuter.java:70)
	at org.gradle.tooling.internal.consumer.connection.LazyConsumerActionExecutor.run(LazyConsumerActionExecutor.java:143)
	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$1$1.run(DefaultAsyncConsumerActionExecutor.java:67)
	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:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)
	at org.gradle.tooling.internal.consumer.BlockingResultHandler.getResult(BlockingResultHandler.java:46)
	at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter.run(DefaultPhasedBuildActionExecuter.java:63)
	at org.gradle.tooling.internal.consumer.DefaultPhasedBuildActionExecuter.run(DefaultPhasedBuildActionExecuter.java:31)
	at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runPhasedModelQuery(EclipseModelUtils.java:111)
	at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runTasksAndQueryCompositeModelWithRuntimInfo(EclipseModelUtils.java:86)
	at org.eclipse.buildship.core.internal.workspace.EclipseModelUtils.runTasksAndQueryModels(EclipseModelUtils.java:60)
	at org.eclipse.buildship.core.internal.workspace.DefaultModelProvider.lambda$fetchEclipseProjectAndRunSyncTasks$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:2380)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2405)
	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:4853)
	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:3951)
	at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4848)
	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:2380)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2405)
	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:408)
	at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporter.importDir(GradleProjectImporter.java:296)
	at org.eclipse.jdt.ls.core.internal.managers.GradleProjectImporter.importToWorkspace(GradleProjectImporter.java:212)
	at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.importProjects(ProjectsManager.java:149)
	at org.eclipse.jdt.ls.core.internal.managers.ProjectsManager.initializeProjects(ProjectsManager.java:111)
	at org.eclipse.jdt.ls.core.internal.handlers.InitHandler$1.runInWorkspace(InitHandler.java:244)
	at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:43)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.lang.NullPointerException: Cannot invoke method startsWith() on null object
	at java_lang_String$startsWith$2.call(Unknown Source)
	at ProtobufPatchPlugin.isValidOutput(/Users/joyy/Library/Application Support/Code/User/globalStorage/redhat.java/1.11.2022092704/config_mac/org.eclipse.osgi/50/0/.cp/gradle/protobuf/init.gradle:172)
	at ProtobufPatchPlugin$isValidOutput.callCurrent(Unknown Source)
	at ProtobufPatchPlugin.getOutputPath(/Users/joyy/Library/Application Support/Code/User/globalStorage/redhat.java/1.11.2022092704/config_mac/org.eclipse.osgi/50/0/.cp/gradle/protobuf/init.gradle:149)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at org.gradle.internal.metaobject.BeanDynamicObject$GroovyObjectAdapter.invokeOpaqueMethod(BeanDynamicObject.java:584)
	at org.gradle.internal.metaobject.BeanDynamicObject$MetaClassAdapter.invokeMethod(BeanDynamicObject.java:511)
	at org.gradle.internal.metaobject.BeanDynamicObject.tryInvokeMethod(BeanDynamicObject.java:196)
	at org.gradle.internal.metaobject.ConfigureDelegate.invokeMethod(ConfigureDelegate.java:77)
	at ProtobufPatchPlugin$_apply_closure1$_closure2$_closure3$_closure4.doCall(/Users/joyy/Library/Application Support/Code/User/globalStorage/redhat.java/1.11.2022092704/config_mac/org.eclipse.osgi/50/0/.cp/gradle/protobuf/init.gradle:80)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at org.gradle.util.internal.ClosureBackedAction.execute(ClosureBackedAction.java:73)
	at org.gradle.util.internal.ConfigureUtil.configureTarget(ConfigureUtil.java:155)
	at org.gradle.util.internal.ConfigureUtil.configure(ConfigureUtil.java:106)
	at org.gradle.util.internal.ConfigureUtil$WrappedConfigureAction.execute(ConfigureUtil.java:167)
	at org.gradle.internal.ImmutableActionSet$SingletonSet.execute(ImmutableActionSet.java:225)
	at org.gradle.internal.MutableActionSet.execute(MutableActionSet.java:38)
	at org.gradle.plugins.ide.eclipse.model.EclipseClasspath.mergeXmlClasspath(EclipseClasspath.java:374)
	at org.gradle.plugins.ide.internal.tooling.EclipseModelBuilder.gatherClasspathElements(EclipseModelBuilder.java:258)
	at org.gradle.plugins.ide.internal.tooling.RunBuildDependenciesTaskBuilder.populate(RunBuildDependenciesTaskBuilder.java:81)
	at org.gradle.plugins.ide.internal.tooling.RunBuildDepe

I guess the fix is not contained in v1.11.2022092704 yet. The fix just merged into master several hours ago

@snjeza

I've merged the suggested workaround, but can someone test @snjeza's proposal for fixing things on Windows, regarding the init scripts not being removed ?

Ok I've tested it and have some new findings.

@snjeza's proposal can make the JVM be terminated normally and thus the temp files will be deleted after the LS exists. But the removal of those temp files causes new problems.

After reloading the window and projects are imported, if manually trigger a reload project request, the server will get a GradleBuild which is cached by Buildship:

https://github.com/eclipse/eclipse.jdt.ls/blob/5b05202dfaa9777765743df3cd84293b2055add5/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/managers/GradleBuildSupport.java#L79

Since the build instance is cached, the argument inside this build instance contains the path of the init scripts which have been deleted actually. Then at

https://github.com/eclipse/eclipse.jdt.ls/blob/5b05202dfaa9777765743df3cd84293b2055add5/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/managers/GradleBuildSupport.java#L105

The operation will fail due to the init script does not exist.

A temporary workaround for this situation could be: (See https://github.com/eclipse/eclipse.jdt.ls/pull/2249/files)

We keep the init scripts on disk to make sure the project reload operation will not fail due to file not found exception.
Cache the location of those init scripts in each session so that we won't generate too many duplicated files in the temp folder.

At least this can make sure the things will work fine. But after this release I think we need to do some follow-up actions including:

Fix the buildship bug to reduce the possibility of generating temp files.
Find out a better way to limit the number of temp files generated.

@jdneo

Thank you all again for looking into this, I appreciate the time and effort here. Sorry about the can of worms haha.

I can confirm what @jdneo said above about the latest release-- the paths used now in the org.eclipse.buildship.core.prefs file are now good/temp-looking ones with no spaces, so that's awesome! But as per what was said, the build still fails because the specified initialization script '/var/folders/_2/6mk1mskj6698fmb0_81nzbgc0000gn/T/init...' does not exist. If there's anything you want me to do, just let me know.

@tthornton3-chwy

@tthornton3-chwy Try running the command Java: Clean Java Language Server Workspace should fix your problem

You're right, cleared things out on the latest version, and now we're good! Thanks for the help and quick support on this. I'm happy to close this out as the issue has been resolved, or keep it open to capture the thread about what ya'll are thinking for next steps on this, whatever you want!

@tthornton3-chwy

Thank you @tthornton3-chwy. I'm closing this one since the issue has been resolved :)

Navigation Menu

Repository navigation

Project cannot be synced when gradle init script path contains white spaces #2692

Environment

Steps To Reproduce

Current Result

Expected Result

Additional Informations

1.10.0

1.11.2022092604

Solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Project cannot be synced when gradle init script path contains white spaces #2692

Description

Environment

Steps To Reproduce

Current Result

Expected Result

Additional Informations

Activity

jdneo commented on Sep 26, 2022

snjeza commented on Sep 26, 2022

rgrunber commented on Sep 26, 2022

tthornton3-chwy commented on Sep 26, 2022

snjeza commented on Sep 26, 2022

CsCherrYY commented on Sep 27, 2022

rgrunber commented on Sep 27, 2022

CsCherrYY commented on Sep 27, 2022

jdneo commented on Sep 27, 2022

CsCherrYY commented on Sep 27, 2022

1.10.0

1.11.2022092604

Solution

snjeza commented on Sep 27, 2022

rgrunber commented on Sep 27, 2022

jdneo commented on Sep 28, 2022

meiliangdeng commented on Sep 28, 2022

jdneo commented on Sep 28, 2022

jdneo commented on Sep 28, 2022

tthornton3-chwy commented on Sep 29, 2022

jdneo commented on Sep 30, 2022

tthornton3-chwy commented on Sep 30, 2022

jdneo commented on Oct 1, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions