[robfrank]

Closes #9

build-native.sh reused whatever jars were in src/arcadedb_embedded/jars. That caused two problems:

• No jars directory given: it never pulled arcadedata/arcadedb:${ARCADEDB_TAG}, so once latest moved, local wheels kept the old engine, and ARCADEDB_TAG had no effect.
• A jars directory given (build.sh's third argument): it ignored it. CI only worked because the directory it passes is src/arcadedb_embedded/jars itself.

The new scripts/stage_jars.sh, sourced by build-native.sh, stages the jars on every build. It first clears earlier jars, including a previous build's bridge jar. Then:

• If build.sh was given a jars directory, it passes the local-jars/lib copy as a new 6th argument, and the jars come from there. A pinned ARCADEDB_TAG that names a different engine than those jars produces a warning.
• Otherwise the jars come from docker run --rm --pull always arcadedata/arcadedb:$tag, so a locally cached latest doesn't count. A failed pull fails the build.

Test plan

• tests/test_stage_jars.py, 8 tests, runs stage_jars under bash with a fake docker on PATH. RED: 4 failed before the script existed.
  • No source: the tag is pulled with --pull always, and stale jars, including a previous bridge jar, are replaced.
  • A source directory replaces stale jars.
  • The CI path (local-jars copy of the artifact) restages and drops leftovers.
  • A failed pull fails.
  • A source that is the jars directory itself is left alone.
  • A pinned tag naming another engine warns; a matching tag or latest doesn't.
  • build.sh passes its jars directory on.
• Real native build on darwin/arm64 with no jars directory, after planting stale-marker-1.0.jar in src/arcadedb_embedded/jars: latest was pulled again (new layers came down), the marker was gone, 86 jars were staged, and the wheel 26.11.1.dev0 built.
• Full suite against that fresh wheel: 1067 passed.
• CI on this PR: every platform goes through the source-directory path.

Coverage

Invariant: a native build bundles exactly the jars it was asked for (the given jars directory, or arcadedata/arcadedb:<tag> as it is now), never a previous build's.

Entry point	Fixed	Tested
build.sh <plat> <py> native, no jars directory	yes	fake-docker test, plus the real build above
build.sh <plat> <py> <jars-dir> native (CI)	yes	the local-jars source test, plus this PR's CI
build-native.sh by hand, no 6th argument	yes, pulls the tag	fake-docker test
build.sh Docker (Linux) build	not affected	the jars come from Dockerfile.build (artifact or image), not src/.../jars

Known gaps: The Linux Docker build takes its base image by tag through FROM arcadedata/arcadedb:<tag> and doesn't force a pull, so a stale local latest image could still be used there. CI always passes the artifact jars, so only local Linux builds without a jars directory are affected. I can file this as a follow-up if you want.

Adversarial pass

1. The "source is the jars dir" branch isn't what CI takes, so the comments and test were wrong. Real. Fixed: the comments now describe CI's actual path (build.sh copies the artifact to local-jars/lib and passes that), and a new test covers it. The same-directory branch stays only as a guard against deleting the source when the script is run by hand.
2. The header says old jars are always removed, but that branch keeps them. Fixed: the comment now names that exception.
3. ARCADEDB_TAG is still ignored silently when a jars directory is given. Fixed: a pinned tag that differs from the engine in the given jars now warns. The issue asked for at least a warning; failing would break builds that deliberately pin jars.
4. The test that build.sh passes its directory only greps the source. True. It is a structural check; the behaviour behind it is covered by the stage tests and by CI, where every platform passes a jars directory.

Review cycles

This repository has no Claude review workflow, so no bot review was waited for. Final state: no-reviewer.

🤖 Generated with Claude Code