What

Adds multipart/form-data support to the reactive (WebFlux) server interface template. Closes #391.

Each form-data part is exposed as its own @RequestPart parameter using the WebFlux multipart API, and the endpoint declares consumes = MediaType.MULTIPART_FORM_DATA_VALUE.

Why

templateReactive.ftlh never branched on request.isFormData — it always wrapped the body in Mono/Flux with @Valid @RequestBody, so reactive multipart uploads had no @RequestPart binding, no consumes, and would rely on the Servlet-only MultipartFile type (unsupported in WebFlux).

Change

• templateReactive.ftlh: for form-data requests, emit one @RequestPart per schema property via a small FreeMarker macro shared by both signature variants (with/without securities). File parts use the WebFlux types — single file → FilePart, file array → Flux<FilePart> — non-file parts keep their declared type. Adds consumes, imports FilePart only when a file part exists, and stops importing the (no longer generated) wrapper model.

Generated output

@RequestMapping(method = RequestMethod.POST, value = "/upload",
    produces = {"application/json"}, consumes = {MediaType.MULTIPART_FORM_DATA_VALUE})
default ResponseEntity<Void> uploadMultipart(
    @RequestPart(value = "someFile", required = false) FilePart someFile,
    @RequestPart(value = "someFiles", required = false) Flux<FilePart> someFiles,
    @RequestPart(value = "someString", required = false) String someString,
    @ApiIgnore final ServerWebExchange exchange) { ... }

Test

• New testReactiveFormDataMultipart fixture + golden UploadApi.java.
• Full engine suite green: Tests run: 119, Failures: 0, Errors: 0.

Version

Bumps 6.6.2 → 6.6.3 across engine, Maven plugin and Gradle plugin.

Note

Builds on #389 (annotated @RequestPart multipart controllers, now merged), which added the shared "don't generate a wrapper model for form-data" change. Rebased onto main, so this PR contains only its own two commits.

🤖 Generated with Claude Code