elharo commented on issue #183: URL: https://github.com/apache/maven-war-plugin/issues/183#issuecomment-5084909528
This feature request describes adding functionality to the `maven-war-plugin` to automatically generate pre-compressed `.gz` (and potentially `.br` Brotli) sidecar files for static assets (like `.html`, `.css`, and `.js`) during the WAR packaging phase. The goal is to allow servlet containers like Tomcat or Jetty to serve these pre-compressed assets directly, saving CPU overhead and leveraging OS-level zero-copy optimizations. In my opinion, this feature request is **no longer relevant or useful** for the `maven-war-plugin` and should be closed. ### 1. It Violates the Separation of Concerns The `maven-war-plugin` is strictly an archiving plugin responsible for collecting and assembling resources according to the Java EE Web Application archive specification. Asset optimization, minification, and compression fall under the domain of frontend build pipelines or resource optimization plugins (e.g., `frontend-maven-plugin`, Webpack, Vite, or dedicated Maven asset plugins). Modifying the core WAR assembler to inspect file extensions, apply compression algorithms, and generate sidecar files introduces unnecessary complexity and bloat into a plugin that should focus solely on packaging. ### 2. Modern Application Architectures The premise of the request assumes that the servlet container (Tomcat/Jetty) is serving the static assets directly to the internet. In modern infrastructure, this is an anti-pattern. Static assets are almost universally served by a reverse proxy (Nginx, HAProxy), an ingress controller, or a Content Delivery Network (CDN) like Cloudflare or AWS CloudFront. These edge layers handle gzip and Brotli compression dynamically and cache the results at the edge, making pre-compression inside the WAR file redundant and obsolete. ### 3. Redundancy with Existing Build Tools For legacy applications where Tomcat still serves static files directly, developers already have dedicated tools to handle build-time compression. Standard frontend build processes (like npm scripts running within `frontend-maven-plugin`) handle compression long before the Maven `package` phase. Adding this logic to the `maven-war-plugin` duplicates functionality that is better handled by ecosystem-specific tools. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
