Split Quarkus / MicroProfile support

[angelozerr]

Today we have MicroProfile / Quarkus support for

• application.properties (completion, hover, validation, code action) for MicroProfile / Quarkus properties.
• java files with codelens (show URL) and hover (show value of ConfigProperty defined in application.properties)

application.properties

The application.properties support is proper managed

• on JDT LS extension side a propertiesProvider extension point is used to collect any properties (MicroProfile ConfigProperty, MP Rest, Quarkus ConfigRoot, Quarkus kubernetes, etc). We have 2 plugins which manages that (one for MicroProfile and one for Quarkus). For this part, there are nothing to do.

• on MicroProfile LS side, the main code is not linked to Quarkus (just profile and some JSON file which manage Level for value which is specific for Quarkus). For the moment I think we can live with that.

So I think for application.properties support, there are nothing to do.

java codelens, hover

For java codelens hover support, it's not very clean:

• on JDT LS extension side

  • codelens for JAX-RS uses quarkus.http.server.port property to retrieve server port although this property is unknown for MicroProfile. We need to provide extensibility for codelens.
  • for hover, it supports only MicroProfile ConfigProperty but in the future we would like to support Quarkus ConfigRoot, so we need to provide extensibility for hover too.

• on MicroProfile LS it's generic (not linked to Quarkus), but MicroProfile LS manages .properties and .java files both. It causes the problem with java formatter. See vscode-quarkus should not be a Java formatter vscode-quarkus#166 because MicroProfile LS returns the format capability to true (because it can format application.properties) but it is not able to format java files.

Solutions

There are 3 solutions to fix the extensibility and problem with MicroProfile LS (java formatter):

Solution 1: Keep MicroProfile LS to manage java

• on MicroProfile LS side, we keep the problem vscode-quarkus should not be a Java formatter vscode-quarkus#166.
  • Pros:
    • nothing to do
    • one process
    • share data (like projectInfo but today we don't need that)
    • will continue to work with IJ
  • Cons : problem with java formatter
• on JDT LS side, we must provide MicroProfile extensions points for codelens, hover, and diagnostics too to support the issue Support for MicroProfile RestClient/Health Diagnostics #217

Solution 2: Create new MicroProfile LS for java

• on MicroProfile LS side, we create a new MicroProfile LS for java
  • Pros :
    • fix java formatter and future support
    • will continue to work with IJ
  • Cons:
    • create a new project
    • we will have 2 processes
    • don't share data (like projectInfo but today we don't need that)
• on JDT LS side, we must provide MicroProfile extensions points for codelens, hover, and diagnostics too to support the issue Support for MicroProfile RestClient/Health Diagnostics #217

Solution 3: Manage java features with JDT LS

With this solution, we skip the language server and manages codelens, hover, etc with new extensions points provided by the JDT LS project.

• Pros:
  • more fast because it will avoid serialization of codelens, hover from JDT LS -> TypeScript -> MicroProfile LS
• Cons:
  • more work on JDT JBoss Quarkus
  • more work on IJ Quarkus

// @jeffmaury

[angelozerr]

Now we have java codelens, hover and diagnostics extension point, MicroProfile and Quarkus stuff are splitted with a clean mean on JDT LS Side.

I close this issue.