Skip to content

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
git clone --depth 1 --branch 4.0.1 https://github.com/rapiddweller/rapiddweller-benerator-ce.git
cd rapiddweller-benerator-ce
java -version
mvn --batch-mode -DskipTests -Djacoco.skip=true compile
mvn --batch-mode -DskipTests -Djacoco.skip=true dependency:build-classpath -Dmdep.outputFile=target/runtime-classpath.txt
java -cp "target/classes:$(cat target/runtime-classpath.txt)" com.rapiddweller.benerator.main.datamimic.DatamimicConverter /path/to/benerator-project /path/to/datamimic-project /path/to/datamimic-project/migration-report.txt

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
<setup>
    <generate name="persons" count="5" target="LogExporter">
        <key name="name" values="'Alice','Bob','Charlie'"/>

        <nestedKey name="notes" type="list" count="1">
            <key name="pet" constant="Dog"/>
            <key name="hobby" values="'Skiing','Sailing'"/>
        </nestedKey>

        <nestedKey name="cars" type="list" minCount="0" maxCount="3">
            <key name="model" values="'Audi Q4 e-tron','Tesla','VW Passat','BMW iX'"/>
            <key name="color" generator="DataFakerGenerator('color_name')"/>
        </nestedKey>
    </generate>
</setup>

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
<generate name="dates" count="1">
    <key name="created" constant="2026-07-30" inDateFormat="%Y-%m-%d" outDateFormat="%d.%m.%Y"/>
</generate>

Migration checklist

  1. Replace unsupported structural concepts with registered elements; do not silently drop behavior.
  2. Replace every consumer with an explicit target or intentionally omit export.
  3. Change every converted <iterate target="X"> with a non-empty target to <generate target="X">.
  4. For <iterate target="">, remove the empty target and retain iterate only when child contexts actually consume the current source row. Otherwise rewrite the stage to the construct that expresses its real purpose.
  5. Port expressions to Python and make nested scope access explicit.
  6. Select generators and converters from the versioned generated catalogs.
  7. Run LSP validation, review migration-summary.md, the optional report, and the Migration Playbook, then execute a small deterministic task before increasing volume.
  8. 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.