Flash5/flash-extensions/flash-ext-web-bundler/docs/build-time.md

Build-Time Manifest Generation

WebBundlerBuild turns an already-built directory into the asset-manifest.json that ClasspathAssetsSource needs (see asset-sources.md). It does not run a frontend build itself — it only scans a directory that already contains the final files:

• VITE: point it at whatever dist/ the existing frontend build tooling already produces.
• STATIC: point it directly at the static asset folder — there's no separate build step.

It's meant to run once per build, from the consumer project's own build, not from the running application (ClasspathAssetsSource is explicitly unsupported in DEV — see dev-lifecycle.md).

Wiring it into a Maven build

No dedicated Flash5 Maven plugin — WebBundlerBuild is a plain class with a main, invoked via the standard exec-maven-plugin, bound to run before the resources are packaged:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>web-bundler-manifest</id>
            <phase>process-classes</phase>
            <goals><goal>java</goal></goals>
            <configuration>
                <mainClass>dev.relism.flash.ext.webbundler.WebBundlerBuild</mainClass>
                <arguments>
                    <argument>${project.build.outputDirectory}/web/dist</argument>
                </arguments>
            </configuration>
        </execution>
    </executions>
</plugin>

This assumes the built frontend (web/dist/, or a static folder) is already copied under target/classes/web/dist by that point — e.g. via maven-resources-plugin's copy-resources goal, or by running the frontend build with an output directory that points there directly. Once the manifest is written alongside those files, they're just classpath resources: a plain mvn package (or maven-shade-plugin for a fat jar) picks them up with no further configuration, and the app can then be configured with .assetsFromClasspath("web/dist").