salesforce / bazel-ls-eclipse Goto Github PK

POC of a Java-only language server for Bazel

Java 92.27% Starlark 6.56% Shell 1.17%

bazel-ls-eclipse's Introduction

This code has been been merged back into bazel-eclipse. No further development activity will happen here.

B2Eclipse

This is the set of Eclipse plugins for developing Bazel projects in Eclipse. Currently supports running in a language server mode only (through the Eclipse JDT LS).

Repository structure

com.salesforce.b2eclipse.jdt.ls - the code which does all that Bazel-related stuff for building classpaths before they can be further processed by JDT.
com.salesforce.b2eclipse.repository - here you can find the outcome of the build (packaged plugins).
com.salesforce.b2eclipse.tests - integration tests for the jdt.ls plugin.
com.salesforce.b2eclipse.ui - a plugin for the client (the one which is connected to the language server for code interactions). It's rather a simple connection provider to a language server, not a full-fledged UI plugin.

Properties

The following properties are passed from the client to configure the plugin:

java.import.bazel.enabled - whether Bazel support should be enabled in JDT LS (disabled by default);
java.import.bazel.src.path - location of sources (relative to a package). Defaults to /src/main/java;
java.import.bazel.test.path - location of test sources (relative to a package). Defaults to /src/test/java.

Assumptions

Root package is not allowed (i.e. there should be no BUILD file beside the WORKSPACE);
A project has to be in a valid state (i.e. no unsatisfied dependencies are allowed);
Each package is to have sources;
Sources of a package are expected to be under the path specified through the following properties: java.import.bazel.src.path, java.import.bazel.test.path (details in the Properties section).
Sources of a package cannot reside in the root of it. They should be in a subdir;
Subpackages are not supported (i.e. package within package).

Future vision

Will be shipped separately as two independent features: standalone feature and as extension for Eclipse JDT LS.

Building from the command line

The following command will install Apache Maven if necessary, then build the server into the /com.salesforce.b2eclipse.repository/target/repository folder:

    $ ./mvnw clean verify

Note: currently, the build can only run when launched with JDK 8.

Features

Code completion
Code navigation

License

This work is dual-licensed under EPL 2.0 and Apache License 2.0. See corresponding files: EPL2.0, Apache License 2.0.

bazel-ls-eclipse's People

Contributors

Stargazers

Watchers

Forkers

mike-serchenia plaird isabella232

bazel-ls-eclipse's Issues

Add Maven build support to B2Eclipse

VSCode Extension publishing

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

Re-implement aspect file parser to support IDEA format

Improve tests (check classpaths)

Add Checkstyle configuration to B2Eclipse

[Test Project] Document projects graph

Separation properties files of initialization params and others plugin properties

Documentation (project setup, vision diagram)

Make b2eclipse.jdt.ls as JDT LS extension

Proper error handling

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)

Classpath containers initialization

LS doesn't refresh build status

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

Fix PackageInfo for WinOS (path separator)

WinOS compatibility issues (test against large demo)

NPE when is called form VSCode

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.

Add negative Project Import test cases

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

Switch to tycho-sourceref-jgit to simplify local build

Provide README.MD for B2Eclipse

Adjust parser to use universal bazelproject file format

Win OS compatibility check (product, integration tests)

Remove version dependency for org.eclipse.jdt.ls.core in target file

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"

Add B2Eclipse JDT.LS Test module

Prepare B2Eclipse update-site

Publish p2 repo to GitHub pages

Make edits in one source to be visible into dependent file

Support rules_jvm_external

Track BUILD and WORKSPACE file changes

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

Update project dependencies produces multiple VSCode dialogs

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

Add JaCoCo code coverage report

Extract Module Import Order algorithm into separate class

Race condition on "initialize" / "initialized"

“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

Review and update documentation (Installation / Developer guide)

Track BUILD and WORKSPACE file changes

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

[Test Project] Shared dependency

Incompatibility with updated Code Generator

GitHub Actions to support basic CI in master branch

Fix missing bazelWorkspaceRootDirectory at project reimport

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)

Make Bazel path configurable with reasonable fallback

(Reimport / Internal Update) Distinguish already imported projects on initialization phase

Use cases:

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