Appendix A: Setup, Versions and Evidence
Reproduce the local checkpoints, understand the build workaround and distinguish new runs from historical and account-dependent evidence.
A reproducible example needs more than a canvas screenshot. It needs the runtime that understands it, the connector and driver versions it uses, the fixture it receives and a check of the behavior it claims. This appendix keeps that inventory outside the first greeting lesson.
Pin the editor and open the projects
Use the separate MuleSoft Book profile introduced in chapter 1. The tested desktop editor is VS Code 1.110.1 on macOS arm64 with ACB pack 1.22.1. The exact installed component extensions are recorded in environment.json in the complete download; pin each component, not only the pack. Use Extensions → gear → Install Another Version, then disable Extensions: Auto Update and Extensions: Auto Check Updates in the profile. Retain the JDK and Mule runtime versions below independently.
These pins describe the tested installation, not the newest releases or an immutable installer. The screenshot computer has a staged VS Code update; its running executable remains 1.110.1. Applying that update and the pending restart has not been validated. Check Help → About and installed extension versions before reproducing the screens.
Open the current checkpoint folder containing pom.xml, then open src/main/mule/app.xml as a canvas. Use Run and Debug for the local application and Testing for the chapter 6/10 suites. Screenshots sometimes show several checkpoint folders in the author’s workspace; select the current project in the run configuration if using that arrangement. A single-folder workspace avoids the ambiguity.
Design-time DataWeave diagnostics can appear where these small projects omit input metadata. They are not runtime test results. First reproduce the documented fixture; then inspect an actual error and the selected project’s configuration rather than suppressing diagnostics globally.
Make a canvas change deliberately
The supplied checkpoints are complete so you can run a known baseline before changing it. To add a processor, select the + at the intended position, search the component name and choose the connector/module shown in the lesson. For a scope, use the insertion point inside its boundary; the plus after the scope changes the enclosing flow instead. Select the new card and fill its General and Advanced fields from the example. Reuse the named connection configuration unless the lesson creates a new one.
Use fx for a DataWeave expression and text mode for a literal. Where the field already displays #[ and ], enter only the expression between them. Full Transform Message scripts include their %dw 2.0 header and output declaration. Click out of the field to apply the edit, save, hot-deploy, and send the same fixture again. Restore the checkpoint’s baseline before using its verifier. To compare a larger change, keep a copy of the previous checkpoint and reopen the finished current one separately.
The pinned editor can show design-time errors as well as warnings. For example, its File Read metadata can infer Binary at a following object selector even though the documented JSON MIME type and runtime fixture produce a parsed object. Inspect Problems and the component metadata; the screenshots do not claim a diagnostics-free workspace. The local runtime evidence below tests the specific fixture paths.
The component configuration guide and MUnit guide provide vendor reference details. Their current screens may differ from the installed snapshot used here.
Obtain the runtime through supported tooling
Install Anypoint Code Builder and obtain an appropriately licensed or valid evaluation Mule runtime through MuleSoft’s supported distribution. The public companion contains source, not the runtime or a license. Follow the platform’s current entitlement and installation instructions for your account. Code Builder setup.
The normal lessons run through ACB. For the optional standalone verification harness, create an isolated runtime directory for the book. Do not reuse a directory serving other applications. Set JAVA_HOME to the Java 17 installation and MULE_HOME to the teaching runtime, then verify both java -version and mvn -version — the second is the one that reveals which Java Maven actually runs.
The command-line baseline uses Maven 3.9.4 and Python 3. The HTTP harness and controlled services use Python’s standard library. If Maven is installed under another executable path, set the companion’s MAVEN variable to that executable. Shell, IDE and CI environments can select different tools unless those choices are explicit.
The Code Builder runtime used here needed apps, domains/default and orders-data created before standalone startup:
mkdir -p "$MULE_HOME/apps" "$MULE_HOME/domains/default" "$MULE_HOME/orders-data"Its role is directory setup, not the deployment of a custom shared-resource domain.
Reproduction pins
| Component | Pin used by the progressive local projects |
|---|---|
| Mule / bundled DataWeave | 4.12.3 / 2.12.3 |
| Java used for execution | 17.0.13 |
| Maven / Mule Maven Plugin | 3.9.4 / 4.10.0 |
| MUnit runner, tools and plugin | 3.7.4 |
| HTTP / Database / File | 1.11.3 / 1.15.1 / 1.5.5 |
| APIkit / VM / Object Store | 1.11.17 / 2.0.1 / 1.2.2 |
| Local JDBC database | H2 2.3.232 |
These are reproduction pins — not claims that each is the newest release. The account-dependent references separately pin MQ connector 4.0.23, PostgreSQL driver 42.7.5 and Omni Gateway 1.14.0. Changing a connector can change parsing or errors even if the runtime stays fixed.
Mule 4.12 requires a compatible Mule Maven Plugin; the projects retain 4.10.0. Their POMs also retain skipAST=true, the workaround used when the public repository could not resolve the runtime AST-generation BOM. It permits packaging without that pre-generation step. It makes deployment and behavior checks especially important: a successful JAR build can still contain a configuration the runtime rejects.
Maven may need network access to resolve dependencies on a clean machine. The first run can take substantially longer than a cached build. A repository authentication or missing-artifact failure occurs before the flow executes — inspect the coordinate and the repository’s response before changing a working flow. No licensed runtime is silently downloaded by book/run.py.
Follow the companion’s reading order
book/checkpoints.json lists complete runnable checkpoints. Each directory includes its own POM, descriptor, resources, an ACB launch configuration and the stored application configuration; readers do not need an unpublished generator. Start with the finished previous checkpoint to make a change, or open the current finished project to compare it.
book/examples.json and book/EXAMPLES.md map global display numbers to stable example slugs, chapter, source, prerequisites, fixtures, result checks and evidence. The number expresses current reading order. The slug remains the identity when a future edit moves the example.
book/run.py list shows available applications. Chapters 24, 25, 27, 28 and 29 use a policy worksheet, platform project, pipeline or design artifact instead of another local application checkpoint. Their artifacts have explicit paths in the example catalogue.
Run only one orders-learning checkpoint at a time. They share port 18881 and an archive name. The controlled dependency/receiver uses 18882, the TLS workshop 18884 and the representation workshop 18887. MUnit reserves a dynamic listener port so its runtime can coexist with the standalone instance.
Read the evidence at its proper boundary
The progressive edition adds fresh local runs of the chapter checkpoints and representation/TLS workshops. The companion’s dated verification record lists the exact scenarios and final counts. Files under book/actual are generated run output, not source to compare blindly across machines.
The original root application, its results/ records and its separate munit/ application remain historical evidence from 13 September 2026. That baseline had fifteen response checks and four MUnit tests. Its port is 18081, not the progressive application’s 18881. Old passing results do not certify new code, and new results do not rewrite the old observations — the two sets answer different questions and are kept apart for that reason.
The historical probes include Java numeric classes, deferred JSON consumption, Excel and a fixed-width schema. Appendix B points to their complete source and describes what was measured. It does not broaden those observations to every Java object or large-file workload.
Not run. Anypoint account-dependent publication, CloudHub/Runtime Fabric deployment, PostgreSQL execution, MQ broker behavior, SFTP ingestion, API Manager enforcement, Monitoring alerts, Omni traffic, XA recovery and custom-domain deployment require separate acceptance runs. A supplied project or documentation reference is not a passing execution result.
Diagnose setup without changing the business logic
| Symptom | First boundary to inspect |
|---|---|
| Maven uses the wrong Java | mvn -version, shell JAVA_HOME, IDE runner |
| Connector or BOM cannot resolve | Exact coordinate, repository, entitlement, network |
| Package succeeds but deployment fails | Runtime application log and configuration error |
| Address already in use | Existing listener and selected port; MUnit dynamic-port setup |
| Request gets connection refused | Runtime and application deployment, bind address, port |
| A check receives old output | Active checkpoint, deployment completion and retained diagnostic files |
| Repeated hot deployments exhaust metaspace | Isolated runtime process and its JVM memory settings |
During the earlier progressive edition’s repeated redeployments, the runtime’s 256 MB metaspace ceiling was exhausted. The verification runtime was restarted with a 768 MB ceiling. The ACB-edition repeat run used a separate runtime with a 1 GB metaspace ceiling and restarted it between checkpoints. These are test-environment adjustments, not a benchmark or a sizing recommendation for a service.
If a test fails, preserve the actual status/body and relevant log before resetting state. Resets are useful for repeatable synthetic tests but can destroy the evidence needed to understand an unexpected result.
Run against: ACB pack 1.22.1 with the complete installed extension snapshot in environment.json, VS Code 1.110.1, macOS arm64, Java 17.0.13+11 and Mule 4.12.3. On 21 September 2026, 266 HTTP checks passed across the 22 remaining local checkpoints (04–23, 26 and 30) in an isolated standalone runtime. Three MUnit tests passed from ACB Testing; a deliberately incorrect total failed and passed after restoration. Canvas screenshots record editor inspections separately from those runtime checks. Chapters 1–3 retain their 20 September evidence.
Comments