precompile-jsps profile cannot compile any JSP: jetty-jspc-maven-plugin 9.4.0.M0 predates the Jakarta EE 9 migration

[vharseko]

What happens

The precompile-jsps profile fails before it validates a single JSP. It runs
org.eclipse.jetty:jetty-jspc-maven-plugin:9.4.0.M0, which carries the Jetty 9 Jasper built against
javax.servlet.*, while the webapp and every JSP in it have been migrated to jakarta.servlet.*.

The build aborts on ssoadm.jsp, which comes first, so no other page is ever reached — the federation
JSPs under saml2/jsp/, wsfederation/jsp/ and config/federation/ are never compiled at all.

Why it matters

JSP edits currently have no compile-time check. Recent security fixes touching these pages had to fall
back to reproducing each changed scriptlet in a throwaway Java class and type checking it with javac
against the real module classpath. That catches type errors, method names and arity, but it does not
validate the JSP itself — <%@ page import %> directives, tags, and the page structure go unchecked.

How to fix

Either of:

1. Move the plugin to the Jakarta line, matching the Servlet/JSP level the war is built for:
   • Jakarta EE 9 (Servlet 5.0 / JSP 3.0) → org.eclipse.jetty:jetty-jspc-maven-plugin:11.0.x
   • Jakarta EE 10 (Servlet 6.0 / JSP 3.1) → org.eclipse.jetty.ee10:jetty-ee10-jspc-maven-plugin:12.0.x
     (in Jetty 12 the plugin moved to the ee9/ee10 artifacts; the old coordinate no longer exists)
2. Call org.apache.jasper.JspC directly from exec-maven-plugin or maven-antrun-plugin, with
   org.apache.tomcat:tomcat-jasper (plus tomcat-el-api, tomcat-juli) of the same branch the
   deployment runs on. This keeps the JSP compiler identical to the runtime one.

Constraints to keep in mind

• The goal is validation, not shipping precompiled servlets. Generating .java and running javac
  is enough; the generated web.xml fragment must not be merged. Several pages are declared as
  <jsp-file> servlets mapped on /SPSloInit/* and the like, so merging precompilation would change
  those mappings — a behavioural change, not a check.
• ssoadm.jsp may still fail for reasons of its own after the plugin is replaced. Excluding it and
  validating everything else is worth far more than the current state, since it is what blocks the queue.
• Set sourceVersion / targetVersion to the project's release level.
• The profile may have further couplings in the POM (a webXmlFragment, ordering against
  maven-war-plugin); those need checking and may add work beyond swapping the plugin coordinates.