slachiewicz opened a new pull request, #884:
URL: https://github.com/apache/incubator-xtable/pull/884
## 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
