Mitigate vscode-quarkus & springboot tools competing for application.properties

[fbricon]

application.properties (and .yaml) are used both by Quarkus and SpringBoot applications for declaring configuration.
Both vscode-quarkus and springboot-tools extensions use similar file patterns to define the file's language:

vscode-quarkus/package.json

Lines 69 to 76 in daadbe7

	{
	"id": "quarkus-properties",
	"aliases": [
	"Quarkus properties"
	],
	"filenames": [
	"application.properties"
	],

vs
spring-boot/package.json:

    "languages": [
      {
        "id": "spring-boot-properties-yaml",
        "aliases": [
          "Spring Boot Properties Yaml"
        ],
        "filenamePatterns": [
          "application*.yml",
          "application*.yaml",
          "bootstrap*.yml",
          "bootstrap*.yaml"
        ],
        "configuration": "./yaml-support/language-configuration.json"
      },
      {
        "id": "spring-boot-properties",
        "aliases": [
          "Spring Boot Properties"
        ],
        "filenamePatterns": [
          "application*.properties",
          "bootstrap*.properties"
        ],
        "configuration": "./properties-support/language-configuration.json"
      }
    ],

When both extensions are installed and enabled, spring's application.properties might be detected as Quarkus properties, and vice-versa, it's unclear which extension takes precedence (I've seen both cases).

It's pretty easy, but not necessarily obvious, that one can switch to the proper file type/language via the vscode status bar.

So it'd be helpful if there was a way to accurately detect the type of properties we're dealing with, to prevent both extensions from overlapping.

Detecting the project dependencies would require server-side computing, but AFAIK, the only way to do the language distinction is via declarative setting in package.json.

If each framework provided identifiable elements on the 1st line of their application properties, we might be able to make that distinction by leveraging the firstLine property, like in xml:

"firstLine" : "(\<\?xml.*)|(\<svg)|(\<\!doctype\s+svg)"

So having # quarkus vs # springboot on the 1st line might help. But I'm afraid the generic glob patterns will take precedence 1st, so we'll be back to square 1. And the existing thousands of projects out there will not have that identifier anyway.

application.yaml are not defined as quarkus files, since we're simply contributing a custom schema to vscode-yaml, but springboot tools will definitely take over.

We might just need vscode to provide more facilities to identify/register languages.

So there, let's discuss @martinlippert, @aeschli, @emmanuelbernard, @philwebb

[philwebb]

It would be unfortunate to make users edit their property files with a comment just to get the tooling to work.

I wonder if it would be possible to create some kind of shared generic "application properties" plugin that would then delegate to other plugins. So the application.properties and application.yml files get associated with ApplicationConfigPlugin then that plugin would loop over delegates and call them when a match was found:

public String[] doTheThing() {
    for(ApplicationConfigSupport support : getSupportPluginsSomehow()) {
        if (support.isFor(project)) {
            return support.doTheThing();
        }
    }
    return null;
}

It's probably clear that I've not looked at how VSCode plugins works, so apologies if this is a daft idea.

[aeschli]

There's an vscode API to set the language of an editor: languages.setTextDocumentLanguage
You have to listen to active documents and set the language if it doesn't match. Maybe prompt the user before doing so, unless you are 100% sure

[martinlippert]

Another option would be: forget about the specific language definitions and use a common one for property files (same for YAML). Then we would register the language servers for this common language ID, so they would run both (in this case). Then push down the responsibility to the language server whether to work on that file or not. The language server could, for example, take specific filename patterns into account + specific libraries on the classpath of the project (to finally make sure that the file belongs to a certain kind of project: Spring Boot, Quarkus, whatever...).

The downside of this is probably that both language servers would be started and running for the same file, while only one (hopefully) would decide to actually do something.

[martinlippert]

There's an vscode API to set the language of an editor: languages.setTextDocumentLanguage
You have to listen to active documents and set the language if it doesn't match. Maybe prompt the user before doing so, unless you are 100% sure

I like that, too. The question here would be: which extension implements this? To be as independent from each other as possible, both extensions would need to implement this, decide somehow whether this is a Spring or a Quarkus thing, and then set the active language. But in case the file doesn't contain anything that indicates which language to use, this would require communication with a language server (in our case), which would require activating the ls, etc. Or maybe I am missing something.