finish work on project-related XSD namespace resolution for XML language server

[martinlippert]

Spring uses a specific lookup mechanism for XML namespace definition files that loads XSD files from projects instead of from the web using the URL. Support for this was implemented a long time ago for the (old) XML tooling in Eclipse (from the WTP project) as part of the Spring IDE and got extracted into a self-contained feature that got re-used as part of the Spring Tools 4 for Eclipse. That makes the project-based XSD namespace resolution work for the old WTP-based XML support in Eclipse.

For Spring Tools 4, we recently adopted the Wild Web Developer features to support working on modern web applications (see #354). As a side effect of adopting this new feature from Eclipse, the Eclipse-based IDEs now have two different sorts of XML support: the old one from WTP and a new one from Wild Web Developer, which is based on an XML language server (https://github.com/eclipse/lemminx).

A result of this side effect is that both tooling for XML now validates XML files by default. But the XML language server doesn't know anything about the project-related XSD namespace lookup mechanism that was implemented for the old WTP-based XML tooling, so that validation errors appear in certain cases (e.g. #447).

Therefore, we went ahead and implemented an extension to the XML language server, so that the XML language server can use the project-related XSD namespace lookup mechanism as well. In order to do that, we did:

The main implementation is at:
787aa0f

In order to make this work, a few more changes to other projects where necessary:

• Support for 'xml/executeClientCommand` access to server from extension eclipse-lemminx/lemminx#905
• Support 'xml/executeClientCommand' request redhat-developer/vscode-xml#339
• Support for 'xml/executeClientCommand' protocol extension eclipse-wildwebdeveloper/wildwebdeveloper#543
• https://git.eclipse.org/r/c/lsp4e/lsp4e/+/170859
• Relax version constraint on wwd eclipse-m2e/m2e-core#35
• Lenninx maven 0.2.0 snapshot eclipse-m2e/m2e-core#31

With that, the work is almost done. The two remaining items that need more work in order to ship this are:

• the validation in the XML language server doesn't seem to take the specialized namespace resolver into account - or our implementation is too slow. The validation still happens super quickly after opening an XML file and shows wrong errors (based on non-project-related lookup) and that error doesn't go away.

• content-assist works as soon as the initial lookup inside of the classpath of the project is done, but that takes way too long. Hitting content-assist for the first time typically shows wrong results (non-project-related lookup) or takes ages to populate. While this isn't a huge difference compared to the old implementation for the WTP-based XML tools, it feels way too slow for the modern world of language-server-based tooling.

This ticket tracks the work that is necessary to solve those two remaining issues.

[BoykoAlex]

eclipse-lemminx/lemminx#954 (comment)

[BoykoAlex]

@martinlippert I have linked my question to Angelo. He suggested to use resolveEntity(XMLResourceIdentifier resourceIdentifier) (it currently returns null, implementation can be added to https://github.com/spring-projects/sts4/blob/master/headless-services/xml-ls-extension/src/main/java/org/springframework/ide/vscode/xml/namespaces/ProjectClasspathUriResolverExtension.java)

The XMLResourceIdentifier instance that the method takes as the parameter doesn't have the path to the file where the NS Uri has been encountered. Looks like the code gets into resolveEntity(XMLResourceIdentifier resourceIdentifier) before Uri resolver should have resolved the encountered NS Uri to projectaware:// uri already...