[MINOR] Upgrade ASF parent POM from 33 to 39 and fix delombok on modern JDKs

[slachiewicz]

What is the purpose of the pull request

Upgrade the ASF parent POM from 33 to 39, and make delombok work on JDKs newer than 11 so the project can be built locally on a current JDK.

Brief change log

Upgrade ASF parent POM 33 -> 39

Picks up six releases of the Apache parent, most notably newer managed plugin versions (surefire 3.3.0 -> 3.5.6, compiler 3.13.0 -> 3.15.0, enforcer 3.5.0 -> 3.6.3, javadoc 3.7.0 -> 3.12.0) and minimalMavenBuildVersion raised from 3.6.3 to 3.9.

Parent 36 replaced the maven.compiler.source / maven.compiler.target properties with a single javaVersion property, so the compiler configuration has to move with it:

• maven.compiler.target=8 becomes javaVersion=8
• <source>${maven.compiler.source}</source> and <target>${maven.compiler.target}</target> are dropped. After the upgrade ${maven.compiler.source} no longer resolves and appears verbatim in the effective POM; it was inert only because a second, duplicate maven-compiler-plugin declaration set <release>.
• <release> now reads ${javaVersion}

maven-compiler-plugin was declared twice in <build><plugins>, which Maven warns about and which is what let the stale property reference go unnoticed. The two declarations are merged into one.

The Java level stays at 8 and the effective compiler invocation is unchanged: javac [debug release 8].

I also checked the other behaviour changes in this range and they do not affect us: parent 34 moved the apache.snapshots repository into a use-apache-snapshots profile (we never referenced it), and parent 39 dropped useReleaseProfile from the managed release-plugin config (we pin our own release-plugin version and configuration).

Make delombok work on modern JDKs

lombok-maven-plugin 1.18.20.0 is the last release of that plugin (April 2021), so there is no newer version to move to. It embeds lombok 1.18.20, which throws during delombok on JDK 21+:

NoSuchFieldError: Class com.sun.tools.javac.tree.JCTree$JCImport
does not have member field 'com.sun.tools.javac.tree.JCTree qualid'

This overrides the plugin's lombok dependency with the version the project already uses elsewhere, and bumps that from 1.18.36 to 1.18.46 so JDK support extends past 21. CI is unaffected — it stays on Java 11 — but a contributor with a current JDK can now build without hitting this.

Verify this pull request

This pull request is already covered by existing tests.

Verified locally with the project's own wrapper on Temurin 11, matching the Maven CI Build workflow:

• ./mvnw clean install -ntp -B -DskipTests — all 10 modules build cleanly
• Effective POM diffed before and after the parent upgrade; the only compiler-relevant change is the removal of the unresolved ${maven.compiler.source}, with <release>8</release> intact
• The duplicate-plugin-declaration warning is gone
• delombok plus compilation verified on JDK 21, 25 and 26, all three of which failed before the lombok change

These are build configuration changes only and touch no production code, so the existing suite running in CI is the real gate.

The two commits are independent, so I am happy to split the lombok change into its own PR if that is preferred for review.

[slachiewicz]

Rebased onto main, which now carries #884. That moved lombok-maven-plugin into the release profile, so the JDK 21+ fix here moved with it instead of applying at the top level.

That makes one claim in the description above stale: delombok no longer runs on ordinary builds, so a contributor on a current JDK never reaches it. What the override now buys is the ability to cut a release on a modern JDK.

Since the plugin only runs under a profile now, I checked whether release artifacts can drift from what CI builds. They cannot — xtable-api, JDK 26, same commit packaged both ways:

Artifact	Normal build	-DdeployArtifacts=true
Main jar	113 entries	113 entries, every .class byte-identical
Sources jar	not produced	byte-identical to src/main/java
Javadoc jar	not produced	242 HTML files, documents builder/toBuilder
target/delombok	does not exist	63 files, read only by javadoc

<addOutputDirectory>false</addOutputDirectory> is what makes that hold: delombok output never becomes a compile source root, and only maven-javadoc-plugin reads it, through <sourcepath>. Worth treating as load-bearing — flipping it to true would quietly start compiling release jars from delomboked sources while CI keeps compiling the annotated originals.

Which raises a question I would rather have answered than assume: is delombok meant to serve javadoc only, or should the sources jar ship delomboked sources as well?

Today it is javadoc only. Packing delomboked sources would give consumers the generated builders and getters when they attach sources in an IDE. The costs are that the sources jar would no longer match git, and its line numbers would no longer agree with the bytecode's LineNumberTable — which is compiled from the originals — so debugger stepping would land on the wrong lines. Making that coherent means compiling from delomboked sources too, which is a considerably bigger change and reintroduces the drift the table above rules out.

I am happy to leave it exactly as it is. I would just rather it be a decision than an accident of how the config was written.

One related note, since it came up while testing the above: lombok-maven-plugin 1.18.20.0 is genuinely the end of the line — the only newer coordinates on Central are personal republishes (dev.pcms, io.github.qsy7.*), which I would not put in an ASF build. The maintained alternative is lombok's own delombok CLI (lombok.launch.Main) driven by exec-maven-plugin; I checked its output against the plugin's and it is identical apart from the generated-at timestamp header. That is a separate cleanup, not something to fold in here.