This is a clone of the tomcat JspC tool for pre-compiling JSPs (almost all the options have been replicated to have the same command syntax).

It is a maven project so just install or package it. Maven and JDK should be present in the system.

mvn clean package

For the moment the tool should be used using the exec-maven-plugin. So the options should be passed using the exec.args system property of the exec plugin. For example, assuming the WAR exploded application is inside the directory /path/to/webapp, the following commands creates a precompiled-jsp.jar library with all the compiled classes in it:

mkdir -p /precompiled/classes/META-INF
mvn exec:java -Dexec.args="-v -p pre.compiled.jsps -d /precompiled/classes -webapp /path/to/webapp -webfrg /precompiled/classes/META-INF/web-fragment.xml"
cd /precompiled/classes/
jar cvf precompiled-jsp.jar *

The previous example searches all the JSP files inside the webapp application directory and compiles them inside the specified directory (specific JSP files can also passed to the tool). The option -webfrg creates a web fragment standard in the META-INF directory that is automatically parsed by wildfly (by spec). Just adding the JAR file inside the WEB-INF/lib of the app will avoid pre-compilation (the pre-compiled class will be used instead). The complete usage for the utiltity can be shown just using the -help option:

mvn exec:java -Dexec.args="-help"

If the application uses global libraries (wildfly modules, JARs inside an EAR file,...) that are not present in the WAR itself they can be provided to the tool using the -classpath option.

As comented before the implementation tries to follow the same syntax than the tomcat counterpart.

The utility has been done and tested with wildfly 18. Under the hood the maven project is configured to use the needed library versions that are present in that version (jastow, metadata, servlet spec, jstl and jsf modules). The idea is the pom.xml can have different wildfly (and EAP) profiles to work with different versions. Currently only two profiles have been added: wildfly18 and eap72 (wildfly18 is the default one). In order to add a new version of wildfly a new profile should be added with the versions used in that specific release.

For example the wildfly18 profile is defined like this:

<profile>
    <id>wildfly18</id>
    <properties>
        <version.io.undertow.jastow.jastow>2.0.7.Final</version.io.undertow.jastow.jastow>
        <version.org.jboss.metadata.jboss-metadata-web>13.0.0.Final</version.org.jboss.metadata.jboss-metadata-web>
        <version.org.jboss.spec.javax.servlet.jsp.jboss-jsp-api>2.0.0.Final</version.org.jboss.spec.javax.servlet.jsp.jboss-jsp-api>
        <version.org.jboss.logmanager.log4j-jboss-logmanager>1.2.0.Final</version.org.jboss.logmanager.log4j-jboss-logmanager>
        <version.org.apache.taglibs.taglibs-standard-spec>1.2.6-RC1</version.org.apache.taglibs.taglibs-standard-spec>
        <version.org.jboss.spec.javax.faces.jboss-jsf-api>3.0.0.Final</version.org.jboss.spec.javax.faces.jboss-jsf-api>
        <version.com.sun.faces.jsf-impl>2.3.9.SP03</version.com.sun.faces.jsf-impl>
    </properties>
</profile>

Adding a new (or older) version would need to find the exact version libraries used for that version of the wildfly server and create a new profile. For example to build and use the eap72 profile the profile should be passed to the commands:

mvn clean package -P eap72
mvn exec:java -P eap72 -Dexec.args="..."