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...

[ykartsev]

Hi guys. I'm curious if this issue is still in plans or hit a serious blocker? I'm using STS 4.20 with Eclipse and still unable to work with XSD schemas from the JAR. Thank you.

P.S.: I'm afraid to hear something like "everyone is using Java config", so this is not needed :) Hopefully, this is not the case.

[BoykoAlex]

I haven't looked at this for a while... but I vaguely recall hitting some kind of a problem that I wasn't able to resolve... I'd have to dig into it again to recall what the problem was exactly.

[BoykoAlex]

I've reanimated this work. Enabled XML LS extension and fixed a few things on our side and LSP4E to get it running again. So far looks like completion proposals are actually working now and do provide proposals specific to schema from the JAR. The validation, however, is still not working... Seems that Xerces parser needs some kind of an option to resolve the schema from NSURI or its location... The overall observation is that some ops with XML LS become very very slow at first but then once the schema is cached completion proposals becomes fast again.