fix(gradle-plugin): Fix Jackson version conflicts in Gradle plugin via Worker API classpath isolation

[sergeykad]

Fix Jackson version conflicts in Gradle plugin via Worker API classpath isolation

Fixes #18753

When other Gradle plugins (e.g. Spring Boot) place an incompatible Jackson version on the buildscript classpath, the openapi-generator plugin fails with NoSuchMethodError or similar classloading errors. This PR moves code generation into a Gradle Worker API WorkAction with classLoaderIsolation, shielding the generator from buildscript classpath pollution.

Changes

• GenerateWorkAction (new): contains all generation logic extracted from GenerateTask, runs inside an isolated classloader
• GenerateWorkParameters (new): WorkParameters interface mirroring all GenerateTask properties
• GenerateTask: doWork() now submits a GenerateWorkAction via workerExecutor.classLoaderIsolation() instead of running generation inline
• OpenApiGeneratorPlugin: adds openApiGeneratorClasspath configuration for users who need extra jars (custom generators); wires missing enumNameMappings and operationIdNameMappings from extension to task
• build.gradle: passes openApiGeneratorVersion system property to tests

How it works

classLoaderIsolation creates a worker classloader that inherits the plugin's own classpath (openapi-generator + correct Jackson) but hides the buildscript classpath. Other plugins' Jackson versions never reach the generator.

How to validate

1. Use a Gradle project that applies both org.openapi.generator and a plugin that brings a conflicting Jackson (e.g. Spring Boot 3.x)
2. Run openApiGenerate — should succeed without NoSuchMethodError
3. Optionally add custom generators via openApiGeneratorClasspath configuration — they should be picked up by the worker

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

---

Summary by cubic

Isolated the OpenAPI Generator Gradle task using the Worker API with classLoaderIsolation to prevent Jackson version conflicts from other plugins (e.g., Spring Boot). Added a classpath hook for custom generators with @classpath tracking and wired missing enum/operationId mappings.

• Bug Fixes

  • Run generation in a Worker API WorkAction with classLoaderIsolation to shield the generator from buildscript classpath (fixes [BUG][kotlin-spring] NoSuchMethodError 'void com.fasterxml.jackson.core.base.GeneratorBase.<init>(int, com.fasterxml.jackson.core.ObjectCodec, com.fasterxml.jackson.core.io.IOContext)' #18753 and NoSuchMethodError from conflicting Jackson versions).

• New Features

  • Added openApiGeneratorClasspath configuration to supply extra jars (custom generators) to the worker and marked it as @classpath for correct up-to-date and build cache behavior.
  • Wired enumNameMappings and operationIdNameMappings from the extension to the task.

^{Written for commit 8368ad3. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 6 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator-gradle-plugin/src/main/kotlin/org/openapitools/generator/gradle/plugin/tasks/GenerateTask.kt">

<violation number="1" location="modules/openapi-generator-gradle-plugin/src/main/kotlin/org/openapitools/generator/gradle/plugin/tasks/GenerateTask.kt:70">
P2: generatorClasspath affects code generation but is annotated @Internal, so Gradle up-to-date checks and build cache ignore changes to openApiGeneratorClasspath, risking stale outputs.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[Picazsoo]

Hi @sergeykad , I opened another PR regarding gradle plugin recently. Can you check whether it makes sense to consolidate both PRs into one?