skip to content

How do you ship a WireMock stub set as a versioned artifact instead of a mounted directory?

level: seniorimportance: nice to knowfreq 36%

answer

  1. same root, different storage
  2. a prefix, not a file path
  3. immutability costs edit-and-see
  4. the launcher needs a real classpath
  5. --load-resources-from-classpath replaces --root-dir

basics

~20 s

Package mappings and __files under one prefix inside a jar and put it on WireMock's launcher classpath. Start standalone with --load-resources-from-classpath naming that prefix. The set then travels as a versioned, published artifact rather than a bind mount.

solid answer

~40 s

WireMock standalone can take its stub set from the classpath instead of the filesystem: `--load-resources-from-classpath` names a path on the classpath that is the *parent* of `mappings` and `__files`, exactly as `--root-dir` names one on disk. So you build a jar whose contents are `stubs/mappings/...` and `stubs/__files/...`, publish it like any other artifact, put it on the classpath of the JVM that starts WireMock, and pass `--load-resources-from-classpath stubs`. Every consumer of the scaffolding-inspection stub set then pulls one immutable, versioned thing rather than mounting a directory whose contents depend on which branch happens to be checked out. The catch is the launch: a bare `java -jar` ignores `-cp`, so a classpath-packaged set needs a launch that builds a classpath rather than the one-line jar invocation.

code

bash · 6 lines
bash
mkdir -p build/stubs/mappings build/stubs/__files
cp scaffolding-inspection-stubs/mappings/*.json build/stubs/mappings/
cp scaffolding-inspection-stubs/__files/*.json build/stubs/__files/

jar --create --file scaffolding-inspection-stubs.jar -C build stubs
jar --list --file scaffolding-inspection-stubs.jar

go deeper

for a junior

Know that WireMock standalone can read its mappings and __files from a jar on the classpath as well as from a directory, and that the flag names the prefix above those two folders.

for a middle

Explain that --load-resources-from-classpath and --root-dir express the same root in two storage shapes, and describe the layout the jar must carry for the flag to resolve anything.

for a senior

Argue the tradeoff concretely: immutability and a published coordinate against the loss of edit-and-restart, and say which one the team's number of consumers actually justifies.

for a principal

Own the answer to which stub set a given build ran against. That question, not elegance, is what makes packaging worth its friction across many teams and repositories.

## Two ways WireMock finds a stub set WireMock standalone reads its stub set from one root, and the root can live in either of two places. Both flags belong to WireMock and both expect the same layout beneath whatever they name. | flag | what it names | layout expected beneath it | who can change it after the fact | |---|---|---|---| | `--root-dir` | a directory on the filesystem | `mappings/` and `__files/` | anyone with write access to the directory | | `--load-resources-from-classpath` | a path on the JVM classpath | `mappings` and `__files` under that prefix | nobody, without rebuilding the jar | The second row is the whole point. A mounted directory is mutable, local and as current as whatever branch is checked out; a jar on the classpath is fixed at the moment it was built and is fetched by name. ## What the jar has to look like inside The flag names a **prefix**, not a file, so the archive must carry the conventional layout under that prefix: - `stubs/mappings/scaffold-inspections-list.json` - `stubs/mappings/file-inspection-created.json` - `stubs/__files/scaffold-SC-4471-inspections.json` Started with `--load-resources-from-classpath stubs`, WireMock resolves `stubs/mappings` and `stubs/__files` from the classpath and builds the same stub set it would have built from a directory. Nothing about the mapping files changes; only where they were read from. ## What you gain - **One name for one set.** Consumers ask for the published artifact instead of agreeing on a filesystem path, so a build agent, a laptop and a container all get identical bytes. - **Immutability.** Nobody edits the scaffolding-inspection stub set in place on a shared machine, because there is no place to edit. - **A real audit trail.** The set is built, published and resolved like any other artifact, so which build consumed which stub set is answerable after the fact. - **No bind mount.** In a container the stub set can arrive on the classpath rather than through a volume, which removes an entire class of path-mismatch failures. - **Fan-out without copying.** Several teams stubbing the same upstream can depend on one published set rather than each keeping a divergent copy of the same JSON. ## What you give up - **Edit-and-see.** With `--root-dir` you change a mapping and restart; with a packaged set you change a mapping, rebuild the jar, republish it and re-resolve it. That loop is fine for a shared contract and painful for exploration. - **A one-line launch.** `java -jar` ignores `-cp`, so a classpath-packaged set needs a launch that assembles a classpath rather than the bare jar invocation everyone reaches for first. - **Obviousness.** A directory of JSON in the repository is discoverable by anyone who opens the repository; a coordinate in a build file is not, and newcomers will hunt for stub files that are not there. - **Fast correction.** When a stub is wrong at three in the morning, editing a mounted file and restarting is a minute; cutting a new artifact is not. ## When a mounted directory is still the right answer Most of the time, honestly. A stub set that only one repository uses, and that changes in the same commit as the code that depends on it, belongs beside that code as a directory: the review that changes the client changes the stub, and the two can never disagree. Packaging earns its keep when the set outgrows one consumer — when several suites, several repositories or several teams stub the same upstream and you need one answer to *which version of the scaffolding-inspection stubs did that build run against?* A useful middle path is to keep the set in a repository as a directory, and publish it as an artifact from the same build. Local development mounts the directory; pipelines resolve the artifact. Both read the same layout, so the two flags stay interchangeable. ## The judgment an interviewer is listening for 1. **Recognise that the two flags are the same idea in two storage shapes.** A candidate who thinks the classpath option is a different feature has not understood the root directory. 2. **Name the cost, not just the benefit.** Immutability and edit-and-see are the same property viewed from two sides, and which one you want depends on how many consumers the set has. 3. **Tie it to a question somebody actually asked.** Artifact packaging is worth its friction exactly when the team has to answer which stub set a red build used, and cannot.

  • Why does a classpath-packaged stub set need more than java -jar?
    Because `java -jar` ignores `-cp` entirely: the jar's own manifest defines the classpath for that launch, so a second jar added with `-cp` is silently not there. A classpath-packaged stub set therefore needs a launch that assembles a classpath containing both the standalone jar and the stub jar, which is the practical price of the packaging.
  • When would you keep the stub set as a plain directory instead?
    Whenever one repository owns it. A stub set that changes in the same commit as the client it stubs belongs beside that client as `mappings/` and `__files/`, because the review that changes one changes the other and they cannot drift. Packaging pays off once several suites or teams share the set and somebody needs to know which version a build ran against.

saying these in an interview costs you the question

  • Treating the classpath option as a different feature from the root directory
  • Pointing the flag at a mappings folder rather than at its parent prefix
  • Expecting java -jar to honour an extra jar added with -cp
  • Packaging a stub set that only one repository will ever use
  • Assuming an immutable stub set can still be hot-edited on a shared machine