[#1114] Fix precompile-jsps profile for the Jakarta EE 9 webapp

[vharseko]

Fixes #1114

The problem

jetty-jspc-maven-plugin:9.4.0.M0 carries the Jetty 9 Jasper — org.mortbay.jasper:apache-jsp built on Tomcat 8.5, i.e. javax.servlet — while the webapp and every JSP in it have been migrated to jakarta.servlet. The generated source shows both worlds in one file:

// Version: JspC/ApacheTomcat8
import javax.servlet.*;
import javax.servlet.http.*;
...
import jakarta.servlet.http.HttpServletRequest;   // from the page's own <%@ page import %>

Failed to execute goal org.eclipse.jetty:jetty-jspc-maven-plugin:9.4.0.M0:jspc
The type jakarta.servlet.http.HttpServletRequest cannot be resolved
Only a type can be imported. jakarta.servlet.http.HttpServletRequest resolves to a package

The build aborts on ssoadm.jsp, which comes first, so nothing else is ever reached — the federation pages under saml2/jsp/, wsfederation/jsp/ and config/federation/ were never compiled at all.

There is a second, less visible blocker: the goal's useProvidedScope defaults to false, and this module resolves both jakarta.servlet-api:5.0.0 and jakarta.servlet.jsp-api:3.0.0 in provided scope. Without that flag the Servlet and JSP APIs are simply absent from the JspC classpath, and every page fails no matter which plugin version is used.

The fix

The module's level is Servlet 5.0 / JSP 3.0 / JSTL 2.0 — Jakarta EE 9 — so the matching plugin is jetty-jspc-maven-plugin:11.0.24, which brings jetty-jakarta-servlet-api:5.0.2, org.mortbay.jasper:apache-jsp:10.0.27 and JSTL 2.0.0. Jetty 12 would be EE 10 and would diverge from the runtime.

The goal is configured for validation only, not for shipping precompiled servlets:

setting	why
useProvidedScope=true	otherwise the provided-scope Servlet/JSP APIs are off the JspC classpath
generatedClasses=target/jspc	the default is target/classes, which would package generated servlets into WEB-INF/classes
mergeFragment=false	the default is true; merging would rewrite the <jsp-file> servlet mappings (/SPSloInit/* and friends) — a behavioural change, not a check
sourceVersion/targetVersion	taken from maven.compiler.* (verified: major 55)

The exclude list is narrowed from four wildcards to the two pages that genuinely cannot compile here: com_sun_web_ui/jsp/version/ButtonFrame.jsp and com_sun_web_ui/jsp/version/Masthead.jsp, which bind com.sun.identity.console.version.*ViewBean from openam-console — not a dependency of this module. The old **/Masthead.jsp pattern silenced three files to cover one; WEB-INF/jsp/Version.jsp and the help/help2 Mastheads compile fine, and userconsole.jsp does not exist in this module. ssoadm.jsp compiles too, so it needs no exclusion.

Verification

mvn -pl openam-server-only -Pprecompile-jsps process-classes

• BUILD SUCCESS; 121 of 123 JSPs compiled, Generation completed with [0] errors in [3896] milliseconds.
• find openam-server-only/target/classes -path "*org/apache/jsp*" → 0 files; no target/web.xml is written. The war is unaffected.
• Generated bytecode is major 55 (Java 11), matching maven.compiler.target.
• Negative test: injecting SAML2Utils.thisMethodDoesNotExist(request) into saml2/jsp/spSSOInit.jsp fails the build with An error occurred at line: [248] in the jsp file: [/saml2/jsp/spSSOInit.jsp], pointing at the JSP source rather than the generated Java. The profile now actually validates.

Not covered here

webAppSourceDirectory is this module's src/main/webapp, so the 286 JSPs in openam-console remain unvalidated. Adding the same profile there fails on Unable to find taglib [jato] for URI: [/WEB-INF/jato.tld] — jato.tld lives only in openam-server-only/src/main/webapp/WEB-INF/, while openam-console/src/main/webapp/WEB-INF/ holds just web.xml and tags. That needs its own change and is worth a separate issue.