Build job reported the errors from unrelated gradle projects outside my workspace

[testforstephen]

Reproduce steps:

1. Use the launch file jdt.ls.socket-stream.launch to launch eclipse.jdt.ls process first.
2. Use vscode-java/Launch Extension - JDTLS Client to attach a VS Code client. And in the launched VS Code client, it opens a gradle project fx2048.
3. Repeat step1 and 2, but in the step 2, open a new gradle project leakcanary.

In the PROBLEMS view, you can see previous fx2048 project errors displayed in my new workspace leakcanary.

This may be one reason for the famous Build failed issue redhat-developer/vscode-java#495.

[testforstephen]

The cause is ProjectsManager#deleteInvalidProjects method skips the gradle project. See code.

private void deleteInvalidProjects(Collection<IPath> rootPaths, IProgressMonitor monitor) {
		List<String> workspaceProjects = rootPaths.stream().map((IPath rootPath) -> ProjectUtils.getWorkspaceInvisibleProjectName(rootPath)).collect(Collectors.toList());
		for (IProject project : getWorkspaceRoot().getProjects()) {
			if (project.equals(this.getDefaultProject())) {
				continue;
			}
			if (project.exists() && (ResourceUtils.isContainedIn(project.getLocation(), rootPaths) || ProjectUtils.isGradleProject(project)) || workspaceProjects.contains(project.getName())) {
				try {
					project.getDescription();
				} catch (CoreException e) {
					try {
						project.delete(true, monitor);
					} catch (CoreException e1) {
						JavaLanguageServerPlugin.logException(e1.getMessage(), e1);
					}
				}
			} else {
				try {
					project.delete(false, true, monitor);
				} catch (CoreException e1) {
					JavaLanguageServerPlugin.logException(e1.getMessage(), e1);
				}
			}
		}
	}

if (project.exists() && (ResourceUtils.isContainedIn(project.getLocation(), rootPaths) || ProjectUtils.isGradleProject(project))

I saw ProjectUtils.isGradleProject(project)) is introduced in the PR 320401b#diff-54b8440d3466866733ad3374655cf2bfR148. Looks like we should only bypass the special case mentioned in the issue #451, and for other cases, use the API ResourceUtils.isContainedIn to determine whether to delete the cached projects.

// @snjeza How do you think about it?

[snjeza]

I can reproduce the issue.

Looks like we should only bypass the special case mentioned in the issue #451, and for other cases, use the API ResourceUtils.isContainedIn to determine whether to delete the cached projects.

Agree.