Proposal: Introduce a Shared `MicroProfile Tools` for IntelliJ

[angelozerr]

Proposal: Introduce a Shared MicroProfile Tools for IntelliJ

Background

Today, there are two IntelliJ-based plugins providing MicroProfile support:

• Quarkus Tools for IntelliJ
• Liberty Tools for IntelliJ

Both plugins integrate the MicroProfile Language Server (MicroProfile LS) for LSP-based features (completion, diagnostics, hover, etc.), and both use LSP4IJ for their client-side LSP integration.

MicroProfile LS requires access to project metadata (e.g., Java classes, annotations) to compute MicroProfile-related features such as property completion in microprofile-config.properties.
This Java source scanning is not performed directly by MicroProfile LS. Instead, it delegates to the IDE integration layer (Eclipse JDT AST in Eclipse/VS Code, IntelliJ PSI for IntelliJ-based IDEs).

Current Situation

The Java class scanning logic for MicroProfile is implemented inside each plugin separately:

• Quarkus Tools implements PSI-based class scanning to collect MicroProfile metadata.
• Liberty Tools copied and adapted the same scanning logic from Quarkus Tools.

As a result:

1. The two implementations have diverged — they no longer provide consistent MicroProfile behavior (e.g., Quarkus Tools includes MicroProfile validation that Liberty Tools does not, and vice versa).
2. The two plugins cannot currently be installed together in the same IDE instance.
   Even if the installation conflict is resolved, both plugins will start their own instance of the MicroProfile LS, leading to duplicate validations, completions, and input help.

Problem Summary

Problem	Description
Code Duplication	Class scanning and MicroProfile integration logic are duplicated and diverging across plugins.
Incompatibility	Installing both Quarkus Tools and Liberty Tools is currently impossible.
Double Language Server Instances	Even if installation succeeds, MicroProfile LS would be launched twice, causing duplicated LSP features.

Proposed Solution

To address these issues, we propose introducing a new IntelliJ plugin:

🧩 IntelliJ MicroProfile Tools

This plugin would serve as a shared foundation for MicroProfile support across multiple IntelliJ-based tools.

Responsibilities

• Provide a single implementation of the IntelliJ-side Java class scanning (using PSI).
• Manage the shared MicroProfile LS instance (so it runs once per IDE, not once per plugin).
• Offer common MicroProfile validation and completion logic for any IntelliJ-based MicroProfile integration.
• Expose extension points allowing Quarkus Tools and Liberty Tools to contribute framework-specific enhancements (e.g., Quarkus config, Liberty runtime integration).

Benefits

• ✅ Consistency — identical MicroProfile behavior across Quarkus Tools and Liberty Tools.
• ✅ Maintainability — no more duplicated or diverging scanning logic.
• ✅ Compatibility — both plugins can coexist and share the same LS instance.
• ✅ Extensibility — future MicroProfile-based tools can reuse the same integration layer.

Prior Art (VS Code Ecosystem)

A similar architecture has already been successfully implemented in the VS Code ecosystem.

• The vscode-microprofile extension provides the core MicroProfile support for VS Code.
• Both vscode-quarkus and Liberty Tools for VS Code extend this shared extension to provide framework-specific features.

This model has proven effective for:

• Reducing duplication of MicroProfile-related logic.
• Providing a consistent user experience across different runtimes.
• Simplifying the integration and maintenance of the MicroProfile LS.

The proposed IntelliJ MicroProfile Tools plugin aims to replicate this successful design for IntelliJ-based IDEs.

Implementation Strategy

1. Extract PSI-based MicroProfile scanning code from Quarkus Tools.
2. Move this logic into a new intellij-microprofile plugin. (MicroProfile Tools for IntelliJ)
3. Make Quarkus Tools and Liberty Tools depend on this new plugin.
4. Refactor both plugins to delegate their MicroProfile integration through this shared module.

Project Hosting Consideration

If this proposal is accepted, the next question is where to host the new plugin.

The recommended option is to host it within the Eclipse LSP4MP repository, alongside the existing MicroProfile Language Server.

Benefits of hosting under LSP4MP

• 🧩 Shared governance and release cycle with the MicroProfile LS.
• 🛠️ Centralized maintenance for all IDE integrations (Eclipse, VS Code, IntelliJ).
• 🤝 Consistency across IDEs, ensuring that all clients use the same MicroProfile LS implementation and metadata model.
• 🌍 Community alignment — the LSP4MP project already represents the official MicroProfile tooling under the Eclipse Foundation.

Long-Term Vision

This new plugin can serve as the official IntelliJ integration for MicroProfile LS, similar to how the Eclipse ecosystem uses org.eclipse.lsp4mp as a common foundation for MicroProfile support across multiple IDEs.

[fbricon]

Sounds like a good plan. The good thing is we don't need to create a new Eclipse project, since LSP4MP covers it, but we still need the initial contribution for a new intellij-lsp4mp repo to be IP-checked. Am I right @waynebeaton?

[fbricon]

and BTW the new extension name should not contain IntelliJ. It should just be Microprofile Tools, in the Jetbrains marketplace

[angelozerr]

and BTW the new extension name should not contain IntelliJ. It should just be Microprofile Tools, in the Jetbrains marketplace

fixed

[yeekangc]

We will want to look at how the common layer should be and works best to enable LSPs that build on it like LSP4MP and LSP4Jakarta.

+1 and useful to have a "MicroProfile Tools" in general.

[mrglavas]

We will want to look at how the common layer should be and works best to enable LSPs that build on it like LSP4MP and LSP4Jakarta.

Ideally this common layer provides the infrastructure for registration / execution of the various LSP components that are contributed by the implementations. Some work was done within Liberty Tools to facilitate sharing common code paths between MicroProfile and Jakarta EE, but I believe this logically belongs in a common layer.

An example is the "group" attribute we introduced to identify which components apply to MP and Jakarta EE:

[angelozerr]

I totally agree that this new IJ plugin should facillitate integration of other language server which require to delegate some stuff on Java Psi side.

For the group I think you speak about local inspection tool that I did with LSP4IJ to categorize Qute errors and MP errors.

We should go step by step. My suggestion is that I extract all MP support from IJ Quarkus to create this new plugin and improve LSP4IJ to provide the capability to start a given ls with additional JAR that we use in IJ Quarkus

Once this new plugin will exist you will able to consume it and contribute with missing MP support or with features that you have implemented.

Makes sense?

[angelozerr]

Have you some idea about plugin id?

What about org.eclipse.microprofile.devtools ?

Please give me your suggestion.

[angelozerr]

@fbricon @mrglavas @yeekangc @rgrunber @datho7561 please give me your feedback.

Have you some idea about plugin id?

What about org.eclipse.microprofile.devtools ?

Please give me your suggestion.

[datho7561]

Yeah I think that sounds okay

[yeekangc]

For the end-user visible name, we likely are looking at "Tools for MicroProfile" to align with what is there for VS Code and what was previously established. Otherwise, "Language Server for MicroProfile" can work.

The actual plugin itself will be coming out of Eclipse LSP4MP project? If so, we may consider a plugin ID like org.eclipse.lsp4mp. We support MicroProfile but LSP4MP isn't under MicroProfile directly.

@fbricon, what do you think?

[angelozerr]

For the end-user visible name, we likely are looking at "Tools for MicroProfile" to align with what is there for VS Code and what was previously established. Otherwise, "Language Server for MicroProfile" can work.

Tools for MicroProfile because this IJ plugin is not a language server, it will provides an IJ LSP client which will consume the existing MicroProfile LS.

The actual plugin itself will be coming out of Eclipse LSP4MP project?

Yes it is the idea.

If so, we may consider a plugin ID like org.eclipse.lsp4mp. We support MicroProfile but LSP4MP isn't under MicroProfile directly.

I find lsp4mp is too technical. All IJ plugin that we have at Red Hat have devtools, it is the reason why I have suggested org.eclipse.microprofile.devtools, it means that it is a dev toolings for MicroProfile (where MicroProfile API starts with org.eclipse.microprofile)

@fbricon, what do you think?