[MINOR] Upgrade ASF parent POM from 33 to 39 and fix delombok on modern JDKs - #881
Open
slachiewicz wants to merge 2 commits into
Open
[MINOR] Upgrade ASF parent POM from 33 to 39 and fix delombok on modern JDKs#881slachiewicz wants to merge 2 commits into
slachiewicz wants to merge 2 commits into
Conversation
Picks up six releases of the Apache parent POM, 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 a raised
minimalMavenBuildVersion of 3.9.
Parent 36 replaced the maven.compiler.source/target properties with a
single javaVersion property, so the compiler configuration had to move
with it:
- maven.compiler.target=8 becomes javaVersion=8
- the <source>${maven.compiler.source}</source> and
<target>${maven.compiler.target}</target> entries are dropped; they
would no longer resolve, and <release> already governs the build
- <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.
Java level stays at 8 and the effective compiler invocation is
unchanged (javac [debug release 8]).
lombok-maven-plugin 1.18.20.0 is the last release of that plugin (April 2021) and there is nothing newer to upgrade to. It embeds lombok 1.18.20, which throws on JDK 21+ during delombok: NoSuchFieldError: Class com.sun.tools.javac.tree.JCTree$JCImport does not have member field 'com.sun.tools.javac.tree.JCTree qualid' Override the plugin's lombok dependency with the version the project already uses elsewhere, and bump that to 1.18.46 so the JDK support extends past 21. Verified: delombok and compilation of xtable-api succeed on JDK 21, 25 and 26; before this change they failed on all three.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is the purpose of the pull request
Upgrade the ASF parent POM from 33 to 39, and make
delombokwork 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
minimalMavenBuildVersionraised from 3.6.3 to 3.9.Parent 36 replaced the
maven.compiler.source/maven.compiler.targetproperties with a singlejavaVersionproperty, so the compiler configuration has to move with it:maven.compiler.target=8becomesjavaVersion=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, duplicatemaven-compiler-plugindeclaration set<release>.<release>now reads${javaVersion}maven-compiler-pluginwas 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.snapshotsrepository into ause-apache-snapshotsprofile (we never referenced it), and parent 39 droppeduseReleaseProfilefrom the managed release-plugin config (we pin our own release-plugin version and configuration).Make delombok work on modern JDKs
lombok-maven-plugin1.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+: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 Buildworkflow:./mvnw clean install -ntp -B -DskipTests— all 10 modules build cleanly${maven.compiler.source}, with<release>8</release>intactdelombokplus compilation verified on JDK 21, 25 and 26, all three of which failed before the lombok changeThese 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.