The LSPServer used to discover external plugins (like the Isabelle and UML(?) plugins) via the -Dlspx.plugins property, which had a CSV list of class names of the plugins to load. This has been replaced (since VDMJ 4.5.0-SNAPSHOT) by a system that looks for resource file(s) called "lspx.plugins", which should be included at the top level of each plugin jar. So all we have to do is arrange for plugin jars to be added to the classpath, and they will be loaded automatically.
The lspplugin example in the VDMJ suite uses the new technique. The latest Isabelle plugin uses the technique. I'm not sure about the UML plugin - you will see an lspx.plugins file in the resources of plugins that have been updated, and at the top level of their jars.
The -Dlspx.plugins property will still be respected if it is set, and overrides the resources files, allowing you to explicitly select the plugins you want to load. But I think, by default, this should not be passed from VSCode to the LSPSever, once we update to VDMJ 4.5.0.
The LSPServer used to discover external plugins (like the Isabelle and UML(?) plugins) via the
-Dlspx.pluginsproperty, which had a CSV list of class names of the plugins to load. This has been replaced (since VDMJ 4.5.0-SNAPSHOT) by a system that looks for resource file(s) called "lspx.plugins", which should be included at the top level of each plugin jar. So all we have to do is arrange for plugin jars to be added to the classpath, and they will be loaded automatically.The
lsppluginexample in the VDMJ suite uses the new technique. The latest Isabelle plugin uses the technique. I'm not sure about the UML plugin - you will see anlspx.pluginsfile in the resources of plugins that have been updated, and at the top level of their jars.The
-Dlspx.pluginsproperty will still be respected if it is set, and overrides the resources files, allowing you to explicitly select the plugins you want to load. But I think, by default, this should not be passed from VSCode to the LSPSever, once we update to VDMJ 4.5.0.