The MicroProfile language server is an implementation of the Language Server Protocol, providing language features for:

• Properties files: microprofile-config.properties files from a MicroProfile project.
• Java files (URL CodeLens for JAX-RS, Java MicroProfile snippets, etc).

The MicroProfile language server works alongside the MicroProfile jdt.ls extension which is also located in this repository. The MicroProfile jdt.ls extension is able to index a MicroProfile project for metadata (config properties, documentation, sources, etc.) to provide the MicroProfile language server the information required for the language features. The relationship between the MicroProfile language server and the MicroProfile jdt.ls extension is explained in more detail in the vscode-quarkus contributing guide.

• textDocument/completion
• textDocument/definition
• textDocument/documentSymbol
• textDocument/formatting
• textDocument/rangeFormatting
• textDocument/hover
• textDocument/publishDiagnostics

The following gif demonstrates the textDocument/completion request and response in Visual Studio Code. Click here to view a demo for the rest of the language features.

• Clone this repository
• Navigate to the lsp4mp/microprofile.ls/org.eclipse.lsp4mp.ls folder in your terminal or command line
• Run ./mvnw clean verify (OSX, Linux) or mvnw.cmd clean verify (Windows)
• After successful compilation you can find the resulting org.eclipse.lsp4mp.ls-uber.jar in the lsp4mp/microprofile.ls/org.eclipse.lsp4mp.ls/target folder.

Here are some clients consuming the MicroProfile language server:

• Eclipse with quarkus-lsp4e (POC)
• IntelliJ with intellij-quarkus
• Visual Studio Code with vscode-quarkus

The MicroProfile language server can be extensable:

• to add your own code snippets.
• to manage complex properties.
• to contribute to settings.

Those contribution must be hosted in an external JAR and must be added in the MicroProfile language server classpath. If you are using vscode-microprofile, see the Contributing to properties and Java support section.

Java and properties completion snippets are managed by the MicroProfile LS (snippets on server side) by using Java SPI.

Snippets are described in JSON files using the vscode snippet format.

The "context" key can be provided to specify the condition in which the snippet should appear:

• for properties files: the context/properties (can be String or String array) can be declared by the snippet to show the snippet only if the declared property belongs to the project. If an array of properties were provided, the snippet will be displayed if all properties belongs to the project.

	"Add datasource properties": {
		"prefix": "qds",
		"body": [
			"quarkus.datasource.db-kind=...",
			...
			"quarkus.datasource.jdbc.url=..."
		],
		"context": {
			"properties": "quarkus.datasource.jdbc.url"
		}
	}

means that the snippet is shown only if the project has the quarkus.datasource.jdbc.url property.

• for Java files: the context/type can be declared in the snippet to show the snippet only if the Java type belongs to the project.

  "@Operation": {
    "prefix": [
      "@Operation"
    ],
    "body": [
      ...
    ],
    "context": {
    	"type": "org.eclipse.microprofile.openapi.annotations.Operation"
    }
  }

means that the snippet is shown only if the project has the org.eclipse.microprofile.openapi.annotations.Operation Java Annotation in the classpath. In other words, only when the Java project has a dependency on MicroProfile Open API.

To register a snippet, it must be added in:

• MicroProfileJavaSnippetRegistryLoader if the new snippet is for Java files.
• MicroProfilePropertiesSnippetRegistryLoader if the new snippet is for properties files.

To add external snippets (like Quarkus snippets) an implementation of ISnippetRegistryLoader must be created and registered with Java SPI. See for the quarkus.ls.ext for Quarkus snippets:

• Java Quarkus snippets loader.
• JSON Quarkus snippet.
• Java Quarkus snippets loader must be declared in META-INF/services/org.eclipse.lsp4mp.ls.commons.snippets.ISnippetRegistryLoader

The properties available in microprofile-config.properties come from the external component (ex: MicroProfile JDT LS extension). In some case a property cannot be computed on the external component and must be computed on MicroProfile LS side.

An example of this is the MicroProfile Reactive Messaging properties. Some properties are computed according to the value of a property declared in microprofile-config.properties. In the sample Configuring the Kafka connector, you have these properties

mp.messaging.outgoing.generated-price.connector=smallrye-kafka
mp.messaging.outgoing.generated-price.topic=prices

The topic attribute for mp.messaging.outgoing.generated-price.topic comes from smallrye-kafka which is configured with mp.messaging.outgoing.generated-price.connector=smallrye-kafka.

In other words, mp.messaging.outgoing.generated-price.topic exists only if there is the declaration mp.messaging.outgoing.generated-price.connector=smallrye-kafka

The mp.messaging.outgoing.generated-price.topic property cannot be computed on the external component side because it depends on the value of mp.messaging.outgoing.generated-price.connector. The computation is done on MicroProfile LS side with custom builder by using Java SPI ItemMetadataProviderFactory.

Please see the sample of MicroProfile Reactive Messaging.

In microprofile-config.properties file when a property doesn't exists, there is an unkwown error. The user can configure which unknown property errors to hide in the client settings. It's possible to ignore this error with contribution (ex : camel toolings can ignore validation for all camel.* properties).

To do that in the JAR extension, create the META-INF/lsp4mp/settings.json like this:

{
	"validation": {
		"unknown": {
			"excluded": [
				"camel.*"
			]
		}
	}
}

In this sample all camel properties will be ignored during the validation.