feat: remove EndpointsValidator class

[cromoteca]

This is an alternative to #2666.

EndpointsValidator checks if classes annotated with @Endpoint or @BrowserCallable are in the classpath and, in that case, throws an exception if Spring is not available.

In 24.7 we ask Spring for the list of endpoints, so by definition if there's no Spring, there are no endpoints.

See also the discussion in #2938.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.65%. Comparing base (88b6743) to head (d426f9d).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3167   +/-   ##
=======================================
  Coverage   92.65%   92.65%           
=======================================
  Files          85       85           
  Lines        3187     3187           
  Branches      778      778           
=======================================
  Hits         2953     2953           
  Misses        182      182           
  Partials       52       52           

Flag	Coverage Δ
unittests	92.65% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[taefi]

Prior to the unified platform, the existence of EndpointsValidator was unnecessarily a strong check, since most of the Hilla projects would've been initiated either from start.vaadin.com, Spring Initializr, or the skeleton starters we provide. So the chances of users being confused about using endpoints in a non-spring project was very very low.

Now that we have a unified platform, users can start a Vaadin project without Spring, and later get interested in Hilla, and they can be trapped by browsing/following the docs at a wrong place that just instructs how to create endpoints. In that case, a visible enough warning could prevent confusions, but, failing the application startup still feels unnecessary to me.

[cromoteca]

If you create an endpoint in your application, you have @BrowserCallable in your classpath, which means that you have Hilla. Is there a possibility to create a non-Spring application that contains Hilla dependencies? I don't think that we provide such a thing, but maybe there's another path that users could follow and could need to be warned.

[taefi]

The only scenario I can think of is a Vaadin Flow app that was based on some other containers, and when they've upgraded to 24.4+, they excluded Hilla and possibly any trace of SpringBoot from the dependencies. When adding @BrowserCallable on some class, it only needs the removal of the Hilla exclusion, but they may add exclusions for SpringBoot from Hilla, then that confusion can happen. Feels like an edge case, and we can consider removing that validator altogether.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud