I have implemented build-time OpenAPI generator plugins for both Gradle and Maven that produce an OpenAPI document for a Spring Boot application without leaving a web server running. Before investing further effort into polish, publishing, and documentation, I would like to ask:
Would you be open to accepting these plugins as a contribution to the upstream springdoc/springdoc-openapi project?
The full implementation is in: vpelikh#85
I am happy to adjust scope, naming, module layout, package/group coordinates, and API design to match your conventions. Any contributor-license agreements or project-specific rules are fine with me.
Summary of what is proposed
Two build-time generator plugins, plus a single shared worker module. They let users generate openapi.json / openapi.yaml at build time from a Spring Boot app's runtime classpath without starting a long-lived web server.
- Maven plugin —
springdoc-openapi-maven-plugin, a Mojo (springdoc:generate-openapi) that resolves the worker and its transitive dependencies via Aether and forks it against the project's runtime classpath.
- Gradle plugin —
springdoc-openapi-gradle-plugin, a generateOpenApi task that forks the worker with the Java toolchain's launcher and a configurable timeout.
- Shared worker —
springdoc-openapi-generator-worker, a forked-JVM entry point that boots the application context, lets springdoc-openapi build the spec, writes it to disk, and shuts the context down. It detects WebFlux vs WebMvc from the fork classpath and dispatches to the right generator.
Design notes
- No per-stack configuration. The worker infers WebFlux vs WebMvc from the target app's classpath.
- No fixed port. WebFlux never binds a port (no-op
ReactiveWebServerFactory); WebMvc uses an ephemeral port (0) and shuts down immediately after writing the spec.
- WebFlux is genuinely serverless; WebMvc starts a short-lived container because the servlet model requires a
ServletContext.
- Shared fork classpath shape between the Gradle and Maven plugins keeps both implementations aligned.
I look forward to your feedback.
I have implemented build-time OpenAPI generator plugins for both Gradle and Maven that produce an OpenAPI document for a Spring Boot application without leaving a web server running. Before investing further effort into polish, publishing, and documentation, I would like to ask:
Would you be open to accepting these plugins as a contribution to the upstream
springdoc/springdoc-openapiproject?The full implementation is in: vpelikh#85
I am happy to adjust scope, naming, module layout, package/group coordinates, and API design to match your conventions. Any contributor-license agreements or project-specific rules are fine with me.
Summary of what is proposed
Two build-time generator plugins, plus a single shared worker module. They let users generate
openapi.json/openapi.yamlat build time from a Spring Boot app's runtime classpath without starting a long-lived web server.springdoc-openapi-maven-plugin, a Mojo (springdoc:generate-openapi) that resolves the worker and its transitive dependencies via Aether and forks it against the project's runtime classpath.springdoc-openapi-gradle-plugin, agenerateOpenApitask that forks the worker with the Java toolchain's launcher and a configurable timeout.springdoc-openapi-generator-worker, a forked-JVM entry point that boots the application context, lets springdoc-openapi build the spec, writes it to disk, and shuts the context down. It detects WebFlux vs WebMvc from the fork classpath and dispatches to the right generator.Design notes
ReactiveWebServerFactory); WebMvc uses an ephemeral port (0) and shuts down immediately after writing the spec.ServletContext.I look forward to your feedback.