Migrate Benerator Models to DATAMIMIC¶
Treat migration as a semantic rewrite, not an XML rename. First identify what each Benerator component reads, generates, transforms, and consumes. Then express that behavior with elements and attributes present in the current implementation-generated model reference.
Common mappings¶
| Benerator concept | DATAMIMIC contract | Migration intent |
|---|---|---|
<attribute> or <id> |
<key> |
Write a field to the current product. |
<setting> used per record |
<variable> |
Evaluate a reusable value without writing it directly. |
<part> |
<nestedKey> |
Build a nested object or list. |
consumer |
target |
Select an implementation-registered target. |
type used as the generated product name |
name |
Give the product an explicit output name. |
| BEN/JavaScript expression | Python expression in script |
Re-test name lookup and type behavior. |
<iterate> traverses a required source and exposes the current row to child contexts. It has no target in the current authoring contract. Use <generate> whenever the operation creates or exports a product. The runtime still accepts older target-bearing iterate descriptors so that they can be migrated deliberately.
Do not migrate from a historic static support table. The generated generator, scripting, source, and target references are built from the exact EE version used by the Platform.
Run the official Benerator converter¶
Use the converter from the official Benerator CE project, pinned to release 4.0.1-jdk-11. The release requires JDK 11. Its versioned migration instructions and Migration Playbook describe the converter and the cases that need review.
Build the tagged source and run the converter with the complete Maven dependency classpath:
| convert-benerator-project.txt | |
|---|---|
1 2 3 4 5 6 | |
The third converter argument is an optional report path. Do not replace this command with a call that puts only the Maven Central main JAR on the classpath: that JAR does not contain all converter runtime dependencies.
The converter writes *.datamimic.xml, copies project resources, migrates environment files, and creates migration-summary.md. When a report path is supplied, it also writes the detailed report there. Treat both reports as a work list, not as proof that the migrated project is ready to run.
Rewrite a nested product¶
| nested-product.xml | |
|---|---|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
Root-level values are directly visible in the first generation frame. Nested scopes should qualify local values with this.* and parent values with this.parent.*; see Variable scoping in nested generates.
Replace date converters¶
When the input is textual, inDateFormat defines how it is parsed. outDateFormat defines the required output representation.
| date-format.xml | |
|---|---|
1 2 3 | |
Migration checklist¶
- Replace unsupported structural concepts with registered elements; do not silently drop behavior.
- Replace every consumer with an explicit target or intentionally omit export.
- Change every converted
<iterate target="X">with a non-empty target to<generate target="X">. - For
<iterate target="">, remove the empty target and retainiterateonly when child contexts actually consume the current source row. Otherwise rewrite the stage to the construct that expresses its real purpose. - Port expressions to Python and make nested scope access explicit.
- Select generators and converters from the versioned generated catalogs.
- Run LSP validation, review
migration-summary.md, the optional report, and the Migration Playbook, then execute a small deterministic task before increasing volume. - Review user-facing issue codes and fix unsupported options rather than suppressing them.
The converter performs the mechanical project migration. The review steps above remain mandatory because the Benerator 4.0.1 output can contain target-bearing iterate elements that the current DATAMIMIC authoring contract intentionally reserves for generate.