Skip to content

Add a one-command refresh for the JVM consumers - #77

Merged
estebanzimanyi merged 2 commits into
MobilityDB:masterfrom
estebanzimanyi:tooling/refresh-jvm-chain
Jul 28, 2026
Merged

Add a one-command refresh for the JVM consumers#77
estebanzimanyi merged 2 commits into
MobilityDB:masterfrom
estebanzimanyi:tooling/refresh-jvm-chain

Conversation

@estebanzimanyi

Copy link
Copy Markdown
Member

What

tools/refresh-jvm-chain.sh runs the whole JVM chain from one command, so a MobilityFlink, MobilitySpark or MobilityKafka developer refreshes their facades against the latest MEOS API without walking the four repos by hand:

MobilityDB  ->  provision-meos.sh (catalog + libmeos)  ->  JMEOS jar  ->  consumer facades

Why

The chain composes the per-leg scripts that already exist — provision-meos.sh (added in the base PR), then JMEOS/regen-from-catalog.sh, then the consumer's own Maven build. It adds no derivation of its own, only the sequencing and the sibling checkouts, so it cannot drift from CI.

Interface

  • --consumer <path> — the JVM consumer repo to refresh (has tools/refresh.conf).
  • Siblings default to their latest upstream default branch; --mdb <path> / --jmeos <path> (or $MDB / $JMEOS) point at an existing checkout on any branch, to refresh against a MEOS branch still under development.
  • --families, --skip-tests, --force, --work-dir; a rebuild-skip stamp keyed on both the MobilityDB commit and the family flags.
  • The consumer's last leg is a few lines in its tools/refresh.conf: ENGINE, the Maven BUILD_DIR, the JMEOS_COORDS the build resolves the jar as, and the BUILD_CMD. Each consumer also carries a thin tools/refresh-from-master.sh wrapper that locates this script and calls it.

Dependency

The base is the provision-meos.sh extraction PR, which adds the script this composes; the diff carries both commits. The consumer-side refresh.conf + wrapper are per-repo in MobilityFlink / MobilitySpark / MobilityKafka.

Proof

A local run over MobilityFlink derives libmeos + catalog, builds the JMEOS jar, and regenerates the Flink facades: 116 facade classes / 4136 methods, and the mobility-flink-binding module builds.

…s.sh

The libmeos build and catalog parse lived inline in the provision-meos
composite action, and were transcribed again as prose into every
GENERATION.md "regenerate by hand" section, so the CI path and the by-hand
path could drift.

Move that recipe (configure, build, install, parse) into
tools/provision-meos.sh and have the action call it, so there is one
definition instead of several: a developer refreshing the chain runs the
same script CI does. The action keeps only the runner bootstrapping around
it (checkout, Python, apt). Behaviour is unchanged.
A MobilityFlink, MobilitySpark or MobilityKafka developer refreshing their
facades against the latest MEOS API otherwise walks four repos by hand. This
runs the whole chain from one command:

  MobilityDB -> provision-meos.sh (catalog + libmeos) -> JMEOS jar -> facades

It composes the per-leg scripts that already exist -- provision-meos.sh, then
JMEOS regen-from-catalog.sh, then the consumer own Maven build -- and adds no
derivation of its own, only the sequencing and the sibling checkouts, so it
cannot drift from CI. Siblings default to their latest upstream default branch;
--mdb / --jmeos point at an existing checkout to refresh against a MEOS branch
still under development. Each consumer keeps a few lines in tools/refresh.conf
(ENGINE, BUILD_DIR, JMEOS_COORDS, BUILD_CMD) for its last leg, and a thin
tools/refresh-from-master.sh wrapper that locates this script and calls it.
@estebanzimanyi
estebanzimanyi merged commit e9eda42 into MobilityDB:master Jul 28, 2026
1 check passed
@estebanzimanyi
estebanzimanyi deleted the tooling/refresh-jvm-chain branch July 28, 2026 22:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant