Code generation

PreviousNext

How the Repost Maven plugin generates your Java client: the generator block, the repost:check CI gate, engine pinning, and multi-module aggregation.

The Maven plugin runs the schema engine as part of your build and owns two output trees: generated sources and a discovery resource. This page is the reference for that machinery; for the end-to-end setup, start at the quickstart.

The generator block

A Java generator block sets four things the other languages don't need:

generator javaSdk {
  language       = "java"
  output         = "../target/generated-sources/repost"
  resourceOutput = "../target/generated-resources/repost"
  packageName    = "com.example.repost"
  clientName     = "RepostClient"
}
FieldWhat it owns
outputThe source root. Generated .java files are written under the packageName subdirectory here. Repost owns this tree: it replaces its own files atomically and never touches anything else.
resourceOutputThe resource root. One client.json registry per client is written to META-INF/repost/generated-clients/v1/<id>/ here, so a framework or the aggregator can discover the client at build time.
packageNameThe Java package for the generated models, Webhooks tree, and client.
clientNameThe generated client class name (RepostClient above). Pick a distinct name per schema when a build hosts more than one.

Source and resources are one transaction: a regeneration replaces both together or restores the previous tree. A crash never leaves a half-written client or a stale registry. Point output/resourceOutput at build-output directories (as above); they are regenerated, not committed.

The engine

The plugin resolves and runs a signed, platform-specific schema engine (sh.repost:repost-schema-engine:0.9.0), with nothing else to install. Pin a different engine build with <engineVersion> on the plugin (or -Drepost.engineVersion=…); the checksum and signature are verified before the engine runs, and a mismatch fails the build.

Generate and check

The plugin binds to the build. Two goals:

./mvnw repost:generate

repost:generate runs in the generate-sources phase, so mvn compile already has your client. repost:check regenerates into an isolated directory, hashes the result, and fails if it differs from the committed output without writing to your source tree, the CI gate that proves generated code is in sync. The repost CLI generates the identical tree from the same schema, so a teammate without Maven can regenerate too.

GENERATE versus multi-module AGGREGATE_ONLY

Every module runs in one of two modes (<schemaMode>; default GENERATE):

  • GENERATE: run the engine on this module's schema, emit the client and its registry, and aggregate any client registries found on the compile classpath. This is what a single-module app or a schema library uses.
  • AGGREGATE_ONLY: run no engine and generate no client. Only merge the registries published by dependency modules into one application registry. An application module that consumes clients from several schema libraries uses this so it never regenerates code it doesn't own.

In a multi-module build, each schema library stays GENERATE (it owns and publishes one client), and the application module sets AGGREGATE_ONLY:

<configuration>
  <schemaMode>AGGREGATE_ONLY</schemaMode>
  <integration>SPRING_BOOT</integration>
</configuration>

Continue

Schema workflow

Version the schema with migrations and deploy it to your environment.

Schema
Configuration

Credentials, timeouts, retries, and transport options with production defaults.

Configure
Frameworks

Spring Boot, Jakarta CDI, and the framework-neutral core pattern.

Inject