wro4j is a Java web-resource optimization framework that operates both at runtime (inside a servlet container) and at build time (via a Maven plugin). In production it acts as a servlet filter (WroFilter/ConfigurableWroFilter): it intercepts requests for named resource groups defined in XML, Groovy, or JSON model files, resolves the member JS/CSS files through pluggable UriLocator implementations (classpath, servlet context, remote URL, wildcard, webjars), routes each resource through a configurable chain of ResourcePreProcessor/ResourcePostProcessor implementations (JSMin, various CSS minifiers, UglifyJS, Google Closure, Less, Sass, Bourbon, CoffeeScript, TypeScript, JSHint/CSSLint, CSS import inlining, CSS URL rewriting, data-URI embedding), then merges the result, applies hash-based naming, and serves it with gzip and pluggable caching. The same pipeline is exposed for build-time use by the wro4j-maven-plugin with standalone manager factories, giving linting and minification without a servlet container. The architecture is a modular multi-module Maven project: wro4j-core contains the processing pipeline, model, configuration, HTTP handlers, and SPI/provider discovery; wro4j-extensions adds dozens of third-party processors and integrations (Rhino-embedded JS engines with optional Node.js fallback, webjars locators, Groovy/JSON model factories, lint report formatters); wro4j-maven-plugin provides the build-time MoJos; wro4j-osgi provides OSGi packaging. The framework relies heavily on ServiceLoader-based discovery (ProviderFinder, ConfigurableProvider, META-INF/services), decorator chains for cross-cutting processor concerns, configurable strategy classes for hashing/naming/caching/model factories, a lightweight @Inject-based container, and lazy initialization of heavyweight script engines. The core design is well-abstracted: composable ProcessorDecorator variants, a generic ObjectPoolHelper for pooling non-thread-safe engines, a parallel TaskExecutor, lifecycle callbacks, and self-contained CSS/JS parsing and minification utilities (JSMin, JawrCssMinifier, CssUrlInspector). The test suite is unusually extensive, with golden-file expected outputs for nearly every processor and edge case. Maintenance is ongoing but uneven: the repository has commits as recent as October 2026 and CI runs on JDK 17, yet a large share of the extension ecosystem is technically stale — vendored JavaScript compilers are pinned to very old versions (TypeScript 0.3/0.8, CoffeeScript 1.6.3, sass-0.5.0, jQuery 1.5.2 fixtures), golden-file tests are coupled to those exact compiler outputs, and several processors (Dojo Shrinksafe, Dust, Hogan, CJSON, jsonhpack) are effectively abandonware. There are also duplicated parallel implementations and known thread-safety and test-flakiness issues. For reuse, the core pipeline remains coherent, but the extension processors should be treated as legacy integration points.