Add Jackson 3 support

[jiholee17]

Closes #899

Changes

This PR re-introduces support for Jackson 3 (now configured by default in Spring Boot 4 projects) for projects that use the Kotlin 2 generator (generateKotlinNullableClasses = true) since these are the ones that use the builder, by detecting which versions of Jackson annotations are available on the compile classpath and adding annotations for the available version(s). If neither version is found, codegen defaults to Jackson 2 annotations for backwards compatibility. If both versions are found, codegen adds both annotations and defers to runtime selection behavior.

Affected annotations are:

• @JsonDeserialize in com.fasterxml.jackson.databind.annotation (Jackson 2) and tools.jackson.databind.annotation (Jackson 3)
• @JsonPOJOBuilder in com.fasterxml.jackson.databind.annotation (Jackson 2) and tools.jackson.databind.annotation (Jackson 3)

Examples

Example with both Jackson versions:

import com.fasterxml.jackson.databind.`annotation`.JsonDeserialize as FasterxmlJacksonDatabindAnnotationJsonDeserialize
import tools.jackson.databind.`annotation`.JsonDeserialize as ToolsJacksonDatabindAnnotationJsonDeserialize
...
@JsonTypeInfo(use = JsonTypeInfo.Id.NONE)
@FasterxmlJacksonDatabindAnnotationJsonDeserialize(builder = Country.Builder::class)
@ToolsJacksonDatabindAnnotationJsonDeserialize(builder = Country.Builder::class)
public class Country(
...

Example with single Jackson version:

import com.fasterxml.jackson.databind.`annotation`.JsonDeserialize
...
@JsonTypeInfo(use = JsonTypeInfo.Id.NONE)
@JsonDeserialize(builder = Query.Builder::class)
public class Query(
...

How Jackson version detection works

The plugin wires a lazy provider onto the task's @Input jacksonVersions: SetProperty<JacksonVersion>:

configurations.named("compileClasspath")                                                                                                                                
    .map { it.incoming.resolutionResult.allComponents }   // resolved dependency graph
    .map { JacksonVersionDetector.detect(it) }            // → Set<JacksonVersion>

detect scans the graph's components for the jackson-databind module and keys on group — com.fasterxml.jackson.core → Jackson 2, tools.jackson.core → Jackson 3 (group is the only discriminator, since both lineages share the artifact name jackson-databind). At task execution, jacksonVersions.get() is read into CodeGenConfig, which selects the annotation package; an empty set defaults to Jackson 2.

Safe with the Jakarta EE migration plugin

Detection reads resolutionResult.allComponents — the dependency graph metadata — and never calls getFiles() / resolvedArtifacts. The Jakarta plugin works as an artifact transform that only fires when files are requested, so a metadata-only read never triggers it (and never forces sibling modules to build). That eager-resolution path is what broke the earlier resolvedArtifacts-based attempt.

Safe with the Gradle configuration cache

The task never holds a Configuration or Project (neither is cc-serializable). The chain stays a lazy provider, resolved only at execution or cache-store time — after all dependencies are declared — and only the resulting Set<JacksonVersion> (trivially serializable) is stored. A functional test runs generateJava twice with --configuration-cache --configuration-cache-problems=fail and asserts store-then-reuse.

[iuliiasobolevska]

nit: maybe add a couple of tests to cover various project setups (specifically thinking of muti-module project setups with various combinations of how and where plugin is declared vs. applied)

[iuliiasobolevska]

are there any integration tests that explicitly reference Jackson3? idk if having two sets (Jackson 2 and the same for Jackson 3 would be an overkill)

[iuliiasobolevska]

wdyt of providing a customer-facing property that Gradle plugin consumers can override to specify the Jackson version to use if we detect it incorrectly (so they are not blocked)?

The con is that it's yet another prop that we need to maintain

[iuliiasobolevska]

Shall we consider runtime dependencies as well?

Thinking of a (weird) setup where Jackson is only present on the runtime classpath via transitive dependencies

[iuliiasobolevska]

This line uses an eager getter that will trigger eager resolution at configuration time.
Gradle provides ResolutionResult.getRootComponent(): Provider<ResolvedComponentResult>:
https://docs.gradle.org/current/javadoc/org/gradle/api/artifacts/result/ResolutionResult.html
(since Gradle 7.4+ so it should be totally safe to use) as a config-cache-safe way to feed a resolution result into a task. Also better aligns with our code modernization efforts to play well with Gradle caching.

[iuliiasobolevska]

if you switch to the ResolutionResult.getRootComponent() you'll also need to rewrite the detect() method to start walking from the root of the graph and keep track of visited nodes