STS validates XML although all XML validation is off

[BoykoAlex]

STS validates XML with WST XML Core plugin which is for some reason still being pulled by STS eclipse plugins.

There is another WST plugin: WST SSE Core. It is also often used as a dependency.

I'd try to get rid of WST XML Core and ensure it is part of the STS eclipse distro + remove WST XML Core dependencies.

Seems like WST XML Core is to blame for the validation. Since the UI plugin is missing (good) there is no way to turn WST XML validation off.

(@martinlippert what do you think?)

[martinlippert]

Agree. We should try to use and include the WildWebDeveloper based XML tooling exclusively.

[jvalkeal]

Thanks guys. While this issue was about not able to turn off "legacy" xml validation, is there a way to validate all files manually with validation based on language servers? I personally don't care as legacy feature in eclipse was always a bit hit and miss and nuisance leading to trying to disable things so that you get "green" build.

Just wanted to leave this note here for next person searching similar issues. I know that philosophy in language servers is to kick things when file is opened unless framework specifically try to scan all files.

[BoykoAlex]

LSP does not limit validation to open files only. "Diagnostics" notification messages from LSP can be sent from the LS to the client for non-opened files. Java LS sends problem markers for non-opened files. Boot LS sends some spring specific problem markers for Java files as well project-wide, not just for opened java files.

[BoykoAlex]

Just noticed that STS would pull org.eclipse.wst.xml.core as long as we ship it with org.eclipse.m2e which is always going to be the case. Unless m2e removes WTP XML editing in favour of Lemminx (LS based implementation) or provides a trimmed down m2e.core feature.

[martinlippert]

I think the m2e integration with wtp is optional and something that we include in the product build to allow users to use the WAR packaging type for Spring Boot projects and run those WAR-packaged boot apps on a locally installed Tomcat using the server integration from WTP. We could remove all those bits and pieces, but it would mean that users who would like to use the WAR packaging type would have to install those pieces on their own.