JGen blueprint reference

JGen is Chenile’s Java code generator (repository rajakolluru/chenile-gen). A blueprint is a template tree plus a META-INF/blueprint.json that declares its prompts; the engine copies the tree, renders Mustache templates, renames placeholder paths (__service__, __Service__, …), applies conditional folders (%%jpa=true%%) and runs the blueprint’s init hook. To write your own, see writing blueprints.

git clone https://github.com/rajakolluru/chenile-gen.git && cd chenile-gen
make clean all && source setpath.sh
jgen                                   # interactive: pick a config, then a blueprint
jgen -g <blueprint> -o input.json      # write a sample input contract
jgen -f input.json                     # generate non-interactively

Defaults such as package (com.mycompany.myorg), version and output folder come from the JGen config; jgen -e emits it to ./config for editing.

Blueprint catalogue

Blueprint Generates Since
chenile-service An HTTP Chenile service (-api + -service) —
chenile-headless-service A non-HTTP Chenile service 2.1.31
chenile-ecosystem A complete ecosystem composed from the other blueprints 2.1.31
wfservice A workflow (state-machine) service —
wfcustom A workflow service from your own states XML —
mybatisQuery A metadata-driven MyBatis query module —
minimonolith A deployable Spring Boot mini-monolith —
chenile-process-management A typed, multi-level process application 2.1.31
batch A batch process from a hierarchy JSON —
chenile-interceptor A Chenile interceptor (service policy) —
it An integration-test project —
jgen-blueprint A new JGen blueprint module —

Version gating. A blueprint may declare sinceVersion; JGen validates it against your configured chenileVersion through its OWIZ processor chain before any hook runs or file is written — so you can’t generate code your runtime doesn’t support.

Services

chenile-service

Prompts: service, serviceVersion, destFolder, security (n), jpa (y), cloudSwitchEnabled (n), enableMCP (n). Produces <svc>-api (model + interface) and <svc>-service (controller, implementation, configuration, health checker, error codes, BDD tests, scripts/curl-scripts.sh). Endpoints: POST /<svc>, GET /<svc>/{id}, POST /<svc>/op1.

chenile-headless-service 2.1.31

Prompts: service, serviceVersion, destFolder, registerInServiceRegistry (y). Generates a transport-neutral service — a plain Spring bean with @ChenileController, @ChenileOperation and @ChenileBody, no HTTP routes — reachable in-process, from events or from serverless hosts.

wfservice

Prompts: service, serviceVersion, destFolder, activity (mandatory/optional activities), enablement (config-based enable/disable of states and transitions), jpa, cloudSwitchEnabled, security, enableMCP. Generates an OPENED → ASSIGNED → RESOLVED → CLOSED workflow, its STM XML, actions, entity store, POST /<svc>, GET /<svc>/{id}, PATCH /<svc>/{id}/{eventID} and the /<svc>/info/* introspection endpoints (state diagram, allowed actions, JSON, test cases).

wfcustom

As wfservice, but driven by your own states XML file (xmlFile).

mybatisQuery

Prompts: namespace, namespaceVersion, destFolder, security. Generates a MyBatis mapper (<ns>.xml, including the -count query for pagination) and query metadata (<ns>.json), served at POST /q/<name> by the query controller. See Chenile Query.

Deployables

minimonolith

Prompts: monolith, monolithVersion, destFolder, jpa, cloudSwitchEnabled, security, enableMCP (+ mcpServerName, mcpInstructions), enableServiceRegistry (host the registry), enableServiceRegistryDelegate (+ serviceRegistryUrl), dependencies (the services to host), enableQueryController, enableH2Console. A Spring Boot deployable hosting one or more services; MCP is served at /mcp when enabled.

chenile-ecosystem 2.1.31

Composes the blueprints above into a working system in one folder:

Prompt Default Adds
ecosystem, ecosystemVersion, destFolder — names the enclosing folder and versions
service, monolith ${ecosystem}Service, ${ecosystem}Monolith the HTTP service and its primary mini-monolith
security, jpa n, y applied to generated mini-monoliths
includeServiceRegistry (+ serviceRegistryMonolith, serviceRegistryUrl) n a separate registry host; the primary monolith becomes its delegate
includeCconfig n cconfig in the primary monolith
includeHeadlessService (+ headlessService, headlessMonolith) n a headless service with its own monolith
includeQueryService (+ queryNamespace, queryMonolith) n a MyBatis query service with a query-controller monolith

Each composed project is generated in isolation before being placed together, so filename processing can’t interfere. An enclosing Maven reactor parent POM builds every selected project; their root POMs inherit from it.

Process management and batch

chenile-process-management 2.1.31

Generates a runnable mini-monolith for any number of process types, with arbitrary hierarchy depth and multiple child types. Prompts: application, applicationVersion, destFolder, processSpec (a JSON file), definitionSource (json | database), registerInServiceRegistry (n) + serviceRegistryUrl.

{
  "processes": [
    { "processType": "Import", "inputType": "ImportIn", "fields": {"batchId": "string"},
      "children": ["Partition"], "config": {"partitionSize": "100"} },
    { "processType": "Partition", "fields": {"partitionId": "long"}, "children": ["Record", "Audit"] },
    { "processType": "Record", "fields": {"recordId": "string", "overwrite": "boolean"} },
    { "processType": "Audit",  "fields": {"recordId": "string"} }
  ],
  "cronTriggers": []
}
  • fields map to typed input DTOs (string, int/integer, long, boolean, double); children empty means leaf; parents are derived.
  • implementation: custom (default — an explicit scaffold that throws until you implement it), fileSplit or fileRead (real byte-chunking with SHA-256/byte counts).
  • Optional predecessorProcessType / predecessorArgs chain processes; cronTriggers seed disabled Quartz schedules with typed args.
  • Validation rejects cycles, dangling references, unsafe names and invalid cron/timezone/type values before any file is written.

Output: one reactor — <app>-api, <app>-service, <app>-configurations, <app>-package — running generated workers on the JDBC queue, with definitions emitted as defs.json (or seeded into process_definition, preserving later admin edits). Every process is a Chenile HTTP service behind the administrator key. Examples in bp-process-management/examples include a FileUpload/ChunkUpload pair and a three-level BatchUpload → FileUpload → ChunkUpload.

jgen-cli/bin/jgen.sh -f bp-process-management/examples/file-upload-input.json
cd output/uploads && mvn install
export PROCESS_MANAGEMENT_API_KEY="$(openssl rand -hex 32)"
java -jar uploads-package/target/uploads-exec.jar --spring.profiles.active=dev

batch

Prompts: batch, batchVersion, destFolder, batchJson (the hierarchy). Uses the unified config and predecessor fields as of 2.1.31; prefer chenile-process-management for new typed multi-level work.

Building blocks

chenile-interceptor

Prompts: interceptorName, interceptorVersion, destFolder. Scaffolds a service policy extending BaseChenileInterceptor.

it

Prompts: app, appVersion, entity, destFolder, security. An integration-test project using it-cucumber-utils from chenile-bdd — the same Gherkin run over REST Assured.

jgen-blueprint

Prompts: blueprintName, destFolder, security, jpa, cloudSwitchEnabled. Generates a new blueprint module — JGen generating JGen. See writing blueprints.

Also
jgen-portal is a web UI for running blueprints with per-session workspaces. Each blueprint module (bp-*) holds its blueprint.json, an optional Init…Blueprint hook and its template folder.