salesforce / bazel-ls-eclipse Goto Github PK

Currently we getting next exception on file close/open cycle:
java.lang.IllegalStateException: Attempt to retrieve the classpath of a Bazel Java project prior to setting up the Bazel workspace.
at com.salesforce.b2eclipse.classpath.BazelClasspathContainer.getClasspathEntries(BazelClasspathContainer.java:120)

“initialize” request, which is sent from the client, triggers build process against the current workspace asynchronously without waiting for the finishing of the build:

/* (non-Javadoc)
 * @see org.eclipse.lsp4j.services.LanguageServer#initialize(org.eclipse.lsp4j.InitializeParams)
 */
@Override
public CompletableFuture<InitializeResult> initialize(InitializeParams params) {
	logInfo(">> initialize");
	InitHandler handler = new InitHandler(pm, preferenceManager, client, commandHandler);
	return CompletableFuture.completedFuture(handler.initialize(params));
}

After that the client sends “initialized” notification (see org.eclipse.lsp4j.services.LanguageServer#initialized for JavaDoc).
The handler of the “initialized” notification should wait for the build process to complete (see the code snippet below):

/*
 * (non-Javadoc)
 * @see org.eclipse.lsp4j.services.LanguageServer#initialized(org.eclipse.lsp4j.InitializedParams)
 */
@Override
public void initialized(InitializedParams params) {
	logInfo(">> initialized");
	try {
		Job.getJobManager().join(InitHandler.JAVA_LS_INITIALIZATION_JOBS, null);
	} catch (OperationCanceledException | InterruptedException e) {
		logException(e.getMessage(), e);
	}
...
}

The problem of the synchronization occurs in the case when build jobs are not started yet on the server-side, but the notification is received and the server tries to wait for the initialization jobs to be completed. In this situation, the “join” method returns immediately and lets the execution runs further with wrong results.

for the complete code see org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer

Rebuild project if BUILD and WORKSPACE were change. Implement IBuildSupport extension.

Required changes in external repositories:
eclipse-jdtls/eclipse.jdt.ls#1694
redhat-developer/vscode-java#1825

right after import is finished VSCode sends workspace/didChangeConfiguration command including java.home. during it processing I'm getting:

java.lang.NullPointerException
	at org.eclipse.jdt.ls.core.internal.JVMConfigurator.configureDefaultVM(JVMConfigurator.java:88)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.didChangeConfiguration(JDTLanguageServer.java:432)
	...

recently plugin was made as an extension for eclipse.jdt.ls so we moved to own *.target, *.launch files and sorrowfully missed something - org.eclipse.jdt.launching.macosx have to be added to launch configurations.

project build will fail every time when eclipse.jdt.ls will release new version (e.g. here) as it's number is hardcoded in target definition.
we should make it generic - "0.0.0"

Test case import project build with workspace.
Test case import project build with class.
Test case import project build with subpackage.

Сhanging the build file does not update the dependencies in the Java class

Rebuild project if BUILD and WORKSPACE were change. Implement IBuildSupport extension.

At the moment their import silently breaks

• Incorrect src path produces NPE since no aspects are calculated
• Dependencies on missing targets produce NPE
• Specify restrictions in the readme (such as ignored root package - i.e. BUILD file alongside WORKSPACE, etc)

Use cases:

• Re-Import: changes while VSCode closed (include IDE restart)
• External Update: FS changes while VSCode open
• Internal Update: changes in VSCode

source/test path locations should be overridable via params of initialize request (LSP).
also Bazel support feature of eclipse.jdt.ls should be configurable in the same way.

jdtls + lsp bug (not waiting for jobs to complete)

• GitHub Actions to build project and publish VSX package
• Instruction how to publish extension into VSCode Matketplace (via Azure Pipelines)