[MINOR] Run delombok only in the release profile

[slachiewicz]

What is the purpose of the pull request

Run delombok only where its output is actually used.

${delombok.output.dir} has exactly one consumer: maven-javadoc-plugin in the release profile (-DdeployArtifacts=true), which points <sourcepath> at it so the lombok-generated builders, getters and equals/hashCode appear in the javadoc jar. There is no <reporting> section, and the website build is Docusaurus, so nothing else reads that directory.

The execution itself, though, sat in the top-level <build><plugins> bound to generate-sources — so it ran on every build, CI and local alike, generating a directory that only a release ever consumes.

That matters beyond the wasted work, because it puts lombok-maven-plugin on the path of every ordinary build. Its last release is 1.18.20.0 (April 2021), the project is dormant, and it cannot 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'

So today a contributor on a current JDK is blocked by a plugin whose output they will never look at.

Brief change log

• Move the lombok-maven-plugin / delombok execution from <build><plugins> into the release profile, next to the javadoc plugin that consumes it

Deliberately not removing it: lombok is structural to this codebase — 132 of 207 main sources use it, including 37 of 63 in xtable-api — and 60 main classes have a public surface that is entirely lombok-generated (31 @Value, 40 @Builder/@SuperBuilder, 22 carrying both, plus 18 @Getter/@Data). Dropping delombok would publish a javadoc jar in which InternalTable, SourceTable, ConversionConfig and friends appear to have no builder() and no getters. Delombok genuinely earns its place at release time; it just does not earn it on every build.

Verify this pull request

This pull request is a build configuration change, already covered by the existing build.

Verified on Temurin 11 with the project's own wrapper:

Command	delombok executions	Result
./mvnw install -DskipTests	0	BUILD SUCCESS
./mvnw package -DdeployArtifacts=true -DskipTests	10	BUILD SUCCESS, 6 javadoc jars

The second case is the one that matters, since #728 removed this plugin outright and left the javadoc jar empty until #854 restored it. Unpacking xtable-api-0.5.0-SNAPSHOT-javadoc.jar from this build shows the generated API is present and documented:

• org/apache/xtable/model/InternalTable.InternalTableBuilder.html — the generated builder class has its own page
• InternalTable.html documents builder(), the field getters, and equals/hashCode

So the javadoc is complete, not thinned.

On JDK 21, precisely

This removes one blocker, not all of them. Building xtable-api on Temurin 21:

• on main — fails at lombok-maven-plugin:delombok
• with this change — gets past delombok and fails later at spotless, because google-java-format 1.10.0 requires at least 1.17.0 on JVM 21
• with this change and -Dspotless.check.skip=true — BUILD SUCCESS

There is also a pre-existing javac-21 inference failure in xtable-core (cannot infer type-variable(s) T,K,U,T in BaseFileUpdatesExtractor). So this PR does not make the build JDK 21 ready on its own; it removes the first of three independent obstacles.

Relationship to #881

#881 adds a <dependencies> override to this same plugin so that delombok works on newer JDKs. The two are complementary — that override keeps releases working for whoever cuts one on a modern JDK, while this PR means everyday builds do not invoke the plugin at all. Whichever merges second will need a trivial rebase so the override moves with the plugin block; happy to do that.