Appearance
How do the SDK modes work (monorepo vs connected)?
The erp CLI and the erp-plugin-language MCP server both need grounding data — the JSON Schemas, the catalog of platform capabilities, the block registry, curated examples, these docs. Where that data comes from depends on how the SDK is installed.
The authoring bundle
The grounding data is packaged as an authoring bundle: a folder of schemas/, a frozen catalog.json, blocks.json, validators/, examples/, and the tenant-public docs. It is produced by erp bundle build, which is the only step that reads platform source (it scans the Java for REST mappings and runs esbuild on the validators). Clients never do that scan.
Mode 1 — monorepo (platform developers)
You're working inside the ERP source tree. erp bundle build runs locally against the live source; erp and the MCP server read the freshly built bundle. Everything is always current. This is how these docs were written and how the tutorial module was verified.
Mode 2 — connected (you, a third-party developer)
You have the SDK as a package, and no platform source. Two data sources, in priority order:
erp env syncdownloads your ERP's own authoring bundle from{baseUrl}/api/v1/dev/bundleinto~/.erp/cache/<env>/. This is bundle data generated by your ERP, so it matches exactly the version you're building against — including the live list of entity and theme names in your tenant. Re-run it after every ERP upgrade.- the bundle shipped inside the SDK package — a fallback used when your ERP doesn't expose
/api/v1/dev/bundleyet. It's a snapshot; it may lag your ERP's actual version.
erp env sync --check tells you whether your cached bundle has drifted from what the server would send.
What each mode can and can't do offline
| Capability | monorepo | connected + synced | connected, offline fallback |
|---|---|---|---|
| pull schemas, list blocks, list examples | yes | yes | yes (may lag) |
| validate a page / lint semantics | yes | yes | yes |
erp api ... against the live ERP | yes | yes | no (needs the server) |
erp logs tail for a failed call's stack trace | yes | yes | no — use the ERP admin log view |
| know your tenant's real entity / theme names | yes | yes (from the sync) | no |
| publish a plugin | yes | yes | no |
No Java toolchain required
A pure-JSON plugin (the default shape) needs no JDK, no pf4j jars, no compiled stub. Leave plugin.json's mainClass null and the platform loads the plugin through a built-in generic entry point. You only reach for a Java toolchain if a plugin ships its own Plugin subclass for behaviour the engines can't express — see Create a plugin, and for a complete, real Java-plus-React example, Build a plugin with custom React + Java code. A custom React component on its own, reading data through the generic query engine with no Java at all, is Add a custom block instead.