Try BootUI 2.0 early

BootUI 2.0 was developed on the long-lived v2 branch (v2 plan). To test source changes on your own application, build the checkout into a Maven repository of its own and point your application at that repository. Your regular ~/.m2 repository and the released BootUI versions stay untouched.

What 2.0 adds

• Exact correlation: captured work carrying BootUI's request or execution id joins that owner, with or without tracing, on Spring MVC, WebFlux, and Quarkus. Unsupported, missed or unowned work stays explicit rather than being inferred from an empty report; the stack and agent limits below still apply.
• The runtime journal: one bounded, in-memory record of what the run did, behind Live Activity, request profiles, and run summaries that survive restarts.
• Runtime Insights: observations such as repeated selects, writes behind a GET, errors behind a 2xx, transactions held across a remote call, and anonymous reach of data, each with its counterexample, its evidence, and what to check.
• The change loop: run comparison against the previous run, change impact for a bean, class, table, cache, or host, and the get_runtime_insights, get_runtime_insight, get_runtime_impact, and get_runtime_run_comparison agent tools, also available as bootui insights CLI commands (AI agents).

What 2.0 does not do yet, per stack and for the BootUI Java agent, is listed in Known limitations.

Build the v2 branch

You need JDK 17 or newer and Git. The Maven Wrapper downloads Maven, and the build downloads Node.js for the UI.

git clone https://github.com/jdubois/boot-ui.git
cd boot-ui
git checkout v2
./mvnw -B -ntp -Dmaven.repo.local="$HOME/.m2/bootui-v2" -DskipTests install

Before publication, the branch carried the 1.x version number. A source checkout can still declare the same version as a published artifact, so the separate repository keeps local changes from replacing that artifact in ~/.m2. To pick up later source changes, run git pull and the same command.

Use it in your application

Add BootUI as the setup guide describes, with the version the v2 build installed. A WebFlux application uses the same bootui-spring-boot-starter as a Spring MVC one: the v2 build has no bootui-spring-boot-starter-reactive, and the starter leaves the choice of web stack to the application's own starter. To find the version:

./mvnw -q -Dmaven.repo.local="$HOME/.m2/bootui-v2" -DforceStdout help:evaluate -Dexpression=project.version

Then build and run your application with the same repository:

./mvnw -Dmaven.repo.local="$HOME/.m2/bootui-v2" spring-boot:run
./mvnw -Dmaven.repo.local="$HOME/.m2/bootui-v2" quarkus:dev

The first run downloads your application's other dependencies into that repository. With Gradle, declare it ahead of Maven Central, so the BootUI artifacts resolve from it:

repositories {
    maven { url = uri("${System.getProperty("user.home")}/.m2/bootui-v2") }
    mavenCentral()
}

For the new CLI commands, use the CLI built from the same v2 checkout, not an older installed 1.x command. The build installs its runnable jar in that separate repository; replace VERSION with the version reported above:

java -jar "$HOME/.m2/bootui-v2/com/julien-dubois/bootui/bootui-cli/VERSION/bootui-cli-VERSION-all.jar" insights list

Get a first observation

1. Start the application with BootUI on, as in 1.x, with no extra property. The runtime journal is enabled by default; the optional Java agent adds method and side-effect evidence only when attached and claimed.
2. Run your integration or browser tests against it, or click through its main flows, so it serves realistic traffic.
3. Open Runtime Insights, or use the v2 CLI jar above. Read the coverage strip and the checks that did not run first: an empty list never means healthy. Enabling a sensor or starting Profile resources later cannot recover measurements missed earlier in the run.
4. After a change, restart, run the same traffic, and open the run comparison.

Give feedback

Feedback on 2.0 goes to GitHub Discussions: reply to the pinned v2 feedback discussion, or, until it is pinned, open one in the Ideas category with a title starting with v2:. Useful reports name the stack (Spring MVC, WebFlux, or Quarkus), the observation's kind and status, and whether it was actionable, informative, noise, or misleading on your application. Never paste data you would not publish: Copy for AI and the agent tools mask what BootUI masks, but your application's routes and table names are still yours.

To judge observations the way the 2.0 release does, use the validation report template.