Add springdoc-openapi Gradle + Maven generator plugins as a contribution #3367

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.