feat: include websocket and validation starters in the Spring Boot starter

[totally-not-ai]

Summary

vaadin-spring-boot-starter now also brings spring-boot-starter-websocket and spring-boot-starter-validation. Spring Boot applications that use the starter therefore keep websocket push in the embedded server and BeanValidationBinder working, without adding dependencies of their own.

Why

vaadin-spring stops exporting Spring dependencies at compile scope (vaadin/flow#25927). Until now it pulled in spring-websocket and hibernate-validator transitively, and those are the pieces that

• register the JSR-356 push endpoints in an embedded server, and
• provide the Bean Validation implementation that BeanValidationBinder needs.

A Spring Boot starter is expected to bring the starters it builds on, so the Vaadin starter is the right place for them. The versions still come from the application's Spring Boot version.

Risks

• Applications using the starter get Spring Boot's validation auto-configuration and websocket support on the classpath. Before, they already had hibernate-validator and spring-websocket there through vaadin-spring, so the only new pieces are Spring Boot's own auto-configuration modules for them.

What changed

• vaadin-spring-boot-starter/pom.xml: adds spring-boot-starter-websocket and spring-boot-starter-validation next to spring-boot-starter-webmvc.

How to test

mvn -pl vaadin-spring-boot-starter dependency:tree lists spring-websocket and hibernate-validator under the two new starters.

🤖 Generated with Claude Code

[github-actions]

Dependencies Report

• 🟠 Known Vulnerabilities:

  • Vulnerabilities in: pkg:maven/me.friwi/jcef-api@jcef-ca49ada%2Bcef-135.0.20%2Bge7de5c3%2Bchromium-135.0.7049.85 [CVE-2024-21639, CVE-2024-21640, CVE-2024-9410] (owasp)
    👌 Wait for the update from the jcefmaven community. Meanwhile the swing-kit is supposed to be used with fixed websites and not to browse the internet, we have a check for that, so the only possible attacker would be the same person that created the swing application, aka our customer devs. so this vulnerability is not classified by us as critical issue
    · cpe:2.3:a:chromiumembedded:chromium_embedded_framework::::::::
    · cpe:2.3:a:ada:ada::::::::
  • Vulnerabilities in: pkg:maven/io.opentelemetry/opentelemetry-api@1.65.0 [CVE-2026-54285] (owasp)
    👌 False positive: the advisory is for opentelemetry-js (@opentelemetry/core W3CBaggagePropagator.extract(), fixed in JS 2.8.0) and its only CPE targets node.js. io.opentelemetry is opentelemetry-java, an unrelated codebase on its own 1.x line, so the version range matches only by CPE collision; osv-scanner and ossindex report nothing for this coordinate. It reaches the sbom transitively through selenium-remote-driver under vaadin-testbench, a test only dependency.
    · cpe:2.3:a:opentelemetry:opentelemetry::::::node.js::*
  • Vulnerabilities in: pkg:maven/com.vaadin/vaadin-swing-kit-flow@3.0.1 [CVE-2021-33604] (owasp)
    👌 false report: this CVE is targeting Vaadin version prior 20, swing-kit-flow is using vaadin 24+ version, the related issue has been fixed.
    · cpe:2.3:a:vaadin:flow-server::::::::
    · cpe:2.3:a:vaadin:vaadin::::::::

• 📔 No Core License Issues

• 📔 No License Issues

• 🟠 Changes in 25.4-SNAPSHOT since V25.3.0-rc1

  • 6 packages added (6 external, 0 vaadin)
  • 243 packages modified (17 external, 226 vaadin)
  • 405 packages same (389 external, 16 vaadin)

[Click for more Details]