Delete Java LS configuration

[snjeza]

The related issue - microsoft/vscode-gradle#1649

When an extension contributes a plugin, the plugin is started even if the extension is disabled or even deleted.
See microsoft/vscode-gradle#1441 (comment)

We can

1. delete the Java LS configuration ( < globalStorage > /redhat.java) when calling Clean Java Language Server Workspace
   or
2. create a new action - Delete Java LS Configuration

cc @rgrunber @fbricon @mickaelistria @datho7561

[rgrunber]

Interesting. I don't think I investigated far enough to understand why this happens. @snjeza are you saying once the extension is installed and vscode-java runs, the paths are cached in configuration/. Then even if the extension is disabled/uninstalled (files may not necessarily be deleated), the configuration/ needs an update ?! Does extensions.all include uninstalled extensions ? That part seemed very odd to me.

I remember a while back mentioning that users may be running into issues due to a stale configuration/ that might have even cached an improper wiring to other dependencies, and that there should be a way to re-generate the folder. What do you think of adding this to

vscode-java/src/extension.ts

Lines 432 to 444 in b7bdb0f

	if (cleanWorkspaceExists) {
	const data = {};
	try {
	cleanupLombokCache(context);
	cleanupWorkspaceState(context);
	deleteDirectory(workspacePath);
	deleteDirectory(syntaxServerWorkspacePath);
	} catch (error) {
	data['error'] = getMessage(error);
	window.showErrorMessage(`Failed to delete ${workspacePath}: ${error}`);
	}
	await Telemetry.sendTelemetry(Commands.CLEAN_WORKSPACE, data);
	}

so it's part of the Clean Java Language Server Workspace ? Seems like that's the standard "clean everything and try again" command, though I could understand wanting to keep it separate.

See

vscode-java/src/extension.ts

Lines 1181 to 1199 in b7bdb0f

	async function cleanOldGlobalStorage(context: ExtensionContext) {
	const currentVersion = getVersion(context.extensionPath);
	const globalStoragePath = context.globalStorageUri?.fsPath; // .../Code/User/globalStorage/redhat.java
	ensureExists(globalStoragePath);
	// delete folders in .../User/globalStorage/redhat.java that are not named the current version
	fs.promises.readdir(globalStoragePath).then(async (files) => {
	await Promise.all(files.map(async (file) => {
	const currentPath = path.join(globalStoragePath, file);
	const stat = await fs.promises.stat(currentPath);
	if (stat.isDirectory() && file !== currentVersion) {
	logger.info(`Removing old folder in globalStorage : ${file}`);
	deleteDirectory(currentPath);
	}
	}));
	});
	}

for an idea of how to do it. You probably want to remove the config_* folders, or maybe everything there (including p2/ folders) that matches the current running version.

[snjeza]

for an idea of how to do it. You probably want to remove the config_* folders, or maybe everything there (including p2/ folders) that matches the current running version.

I want to remove ~/<config_folder>//User/globalStorage/redhat.java/. It includes cached plugins (org.eclipse.osgi).

[snjeza]

I don't think I investigated far enough to understand why this happens. ...

Once the plugin is loaded, Eclipse caches it in <eclipse_home>/configuration/org.eclipse.osgi/. Java LS does the same in /redhat.java//config_/org.eclipse.osgi.
Eclipse has the -clear option to clear the configuration. We need something similar to that.

You have faced this issue at microsoft/vscode-gradle#1441 (comment)

Oh, and disabling vscode-gradle isn't enough to make the problem go away...

[datho7561]

Do you think that it would be helpful to keep track of which VS Code extensions/Eclipse plugins are contributed, then when they change, clear this cached plugins folder? I guess that means storing more data to keep track of the changes and would probably still require a command to run the delete manually if detecting the change fails.

[rgrunber]

I think we have some kind of logic that tracks this at

vscode-java/src/standardLanguageClient.ts

Lines 130 to 133 in b7bdb0f

	if (extensions.onDidChange) {// Theia doesn't support this API yet
	extensions.onDidChange(async () => {
	await onExtensionChange(extensions.all);
	});

.

[snjeza]

I suggest Option 1 from the description.

[snjeza]

#4160 implements Option 1.