Is it feasible to drop the activation event `onLanguage:xml`?

[SethFalco]

Describe the bug

I didn't open this up as a PR as I was hoping to ask about it first in case there was a use-case for it beyond what I've figured.

Currently, the extension is set to activate whenever an XML-like file is opened. (Among other conditions.)

I'm looking through the activation events of all my extensions since lately, I've noticed some of them activate eagerly even when they don't apply to my workspace, which can use a lot more resources on my system. This adds up when you have many extensions, i.e. I have 92.

When sorted by MEM% my top 3 processes.

Does it make sense to activate the extension, which then also activates Language Support for Java(TM) by Red Hat, just because an XML file was opened?

I can see you already check for pom.xml in workspaceContains, so I'd think the purpose of onLanguage:xml is in case the user opens an XML Spring config file?

Maybe this would be better:

 {
   "activationEvents": [
     "onLanguage:spring-boot-properties",
     "onLanguage:spring-boot-properties-yaml",
     "onLanguage:java",
-    "onLanguage:xml",
     "onLanguage:spring-factories",
     "onDebugResolve:java",
     "onCommand:vscode-spring-boot.rewrite.list.refactorings",
     "onCommand:vscode-spring-boot.rewrite.list.boot-upgrades",
     "onCommand:vscode-spring-boot.ls.start",
     "workspaceContains:pom.xml",
     "workspaceContains:*/pom.xml",
     "workspaceContains:build.gradle",
     "workspaceContains:*/build.gradle",
     "workspaceContains:settings.gradle",
     "workspaceContains:*/settings.gradle",
     "workspaceContains:build.gradle.kts",
     "workspaceContains:*/build.gradle.kts",
     "workspaceContains:settings.gradle.kts",
     "workspaceContains:*/settings.gradle.kts",
     "workspaceContains:.classpath",
     "workspaceContains:*/.classpath"
   ],
 }

Fun fact, as of VSC 1.74.0 (November 2022), you don't have to specify languages/commands/etc that the extension itself provides. [source]

I think it'd be fair to say if the extension was needed, any of the many other conditions would be met first before onLanguage:xml. Perhaps it'd be better to reduce false-positive activations, especially as this extension causes a fair bit of memory usage?

If you really wanted to activate on all XML files, then maybe we could at least target XML files specifically instead of anything that uses an XML-like file? Though this might actually increase false activations, so might be a dumb idea.

 {
   "activationEvents": [
     "onLanguage:spring-boot-properties",
     "onLanguage:spring-boot-properties-yaml",
     "onLanguage:java",
-    "onLanguage:xml",
     "onLanguage:spring-factories",
     "onDebugResolve:java",
     "onCommand:vscode-spring-boot.rewrite.list.refactorings",
     "onCommand:vscode-spring-boot.rewrite.list.boot-upgrades",
     "onCommand:vscode-spring-boot.ls.start",
-    "workspaceContains:pom.xml",
-    "workspaceContains:*/pom.xml",
+    "workspaceContains:**/*.xml",
     "workspaceContains:build.gradle",
     "workspaceContains:*/build.gradle",
     "workspaceContains:settings.gradle",
     "workspaceContains:*/settings.gradle",
     "workspaceContains:build.gradle.kts",
     "workspaceContains:*/build.gradle.kts",
     "workspaceContains:settings.gradle.kts",
     "workspaceContains:*/settings.gradle.kts",
     "workspaceContains:.classpath",
     "workspaceContains:*/.classpath"
   ],
 }

To Reproduce

Open any non-Java/Spring project with XML files. Given how widely XML is used, this can activate for pretty much any workspace. In my case, it mostly comes from opening SVGs.

Sample

N/A (I think in this case it's fair not to include a sample.)

---

Just a heads-up even setting the onLanguage:xml aside, I believe you can compress the activation events a bit by using the ** wildcard and omitting contributions from the extension itself.

 {
   "activationEvents": [
-    "onLanguage:spring-boot-properties",
-    "onLanguage:spring-boot-properties-yaml",
     "onLanguage:java",
     "onLanguage:xml",
-    "onLanguage:spring-factories",
     "onDebugResolve:java",
-    "onCommand:vscode-spring-boot.rewrite.list.refactorings",
-    "onCommand:vscode-spring-boot.rewrite.list.boot-upgrades",
-    "onCommand:vscode-spring-boot.ls.start",
-    "workspaceContains:pom.xml",
-    "workspaceContains:*/pom.xml",
+    "workspaceContains:**/pom.xml",
-    "workspaceContains:build.gradle",
-    "workspaceContains:*/build.gradle",
+    "workspaceContains:**/build.gradle",
-    "workspaceContains:settings.gradle",
-    "workspaceContains:*/settings.gradle",
+    "workspaceContains:**/settings.gradle",
-    "workspaceContains:build.gradle.kts",
-    "workspaceContains:*/build.gradle.kts",
+    "workspaceContains:**/build.gradle.kts",
-    "workspaceContains:settings.gradle.kts",
-    "workspaceContains:*/settings.gradle.kts",
+    "workspaceContains:**/settings.gradle.kts",
-    "workspaceContains:.classpath",
-    "workspaceContains:*/.classpath"
+    "workspaceContains:**/.classpath"
   ],
 }

[martinlippert]

Thanks for raising this @SethFalco, I totally agree that we should not auto-activate the extension when you don't really need it.

In more detail:

• I agree that activating the extension on random XML files seems to be a bit too much
• Compressing the events by using the ** wildcard seems logical to me
• We can't remove the activation on certain events, they are needed in order to activate the extension in certain events

[SethFalco]

We can't remove the activation on certain events, they are needed in order to activate the extension in certain events

Since VSC 1.74.0, most contributions from the extension are implied to activate the extension. And I believe all the onCommand etc. events are contributed by this extension, right?

The extension will still activate if you remove them! (Not a big deal if you want to leave them anyway, though. Just wanted to elaborate there. Just let me know if you feel I've misunderstood anything.)

Note: Beginning with VS Code 1.74.0, languages contributed by your extension do not require a corresponding onLanguage activation event declaration for your extension to be activated.

Note: Beginning with VS Code 1.74.0, commands contributed by your extension do not require a corresponding onCommand activation event declaration for your extension to be activated.

Note: Beginning with VS Code 1.74.0, views contributed by your extension do not require a corresponding onView activation event declaration for your extension to be activated.

Note: Beginning with VS Code 1.74.0, authentication providers contributed by your extension do not require a corresponding onAuthenticationRequest activation event declaration for your extension to be activated.

[martinlippert]

The extension will still activate if you remove them! (Not a big deal if you want to leave them anyway, though. Just wanted to elaborate there. Just let me know if you feel I've misunderstood anything.)

Ah, I see, awesome. Thanks for pointing that out. In that case, we should definitely adopt that... :-)

[BoykoAlex]

Good topic. I have reviewed activation events in the light of our new Boot LS startup logic, i.e. Boot LS process started when there is spring-boot on the classpath in the workspace.
I believe that none of the onLanguage type of events are relevant anymore as well as presence of build files in the workspace. Boot extension should be activated only for refactoring or upgrade action or when boot ls start command is attempted to be executed. If this command is attempted to be executed this means our JDT LS extension (which is hooked regardless of Boot extension activation) has discovered a spring-boot project.
If build files are found in the workspace or java/yaml/properties/xml file opened in an editor Boot extension is useless for these files unless it a file from a Spring-Boot project.

Therefore my changes are: d84ecc2