aglinxinyuan opened a new pull request, #6267: URL: https://github.com/apache/texera/pull/6267
### What changes were proposed in this PR? Backport of apache/texera#6225 to `release/v1.2`: cap `org.jooq:jooq` at **3.19.36**, the last release that still targets Java 17. jOOQ 3.20+ (Open Source Edition) is compiled to Java 21 bytecode (class file version 65), but `release/v1.2` builds and runs on **Java 17** (class 61) — so any jOOQ ≥ 3.20 fails at runtime with `UnsupportedClassVersionError`. `release/v1.2` currently ships jOOQ 3.16.23 (fine today), but this keeps it aligned with `main` and pins the whole build to a single Java-17-safe jOOQ version. | jOOQ declaration | Before | After | |---|---|---| | `amber/build.sbt` | 3.14.16 | **3.19.36** | | `computing-unit-managing-service/build.sbt` | 3.14.16 | **3.19.36** | | `common/dao/build.sbt` | 3.16.23 | **3.19.36** | | `project/plugins.sbt` (`jooq-codegen`) | 3.16.23 | **3.19.36** | `jooq-codegen` moves in lockstep with the runtime: `javac` runs with `-Xlint:deprecation -Werror`, and a 3.16 codegen emits a `TableImpl(Table, ForeignKey, Table)` call that the 3.19 runtime deprecates, which would fail `DAO / Compile`. The 42.7.4 pgjdbc codegen pin still applies (the KEY_SEQ fix is only in jOOQ 3.20+). **LICENSE-binary / NOTICE-binary were regenerated from `release/v1.2`'s own resolved classpath** (not copied from `main`), across the six service dists that bundle jOOQ (amber, config, access-control, file, computing-unit, workflow-compiling): - jooq bullet `3.16.23 → 3.19.36` in every `LICENSE-binary`. - `amber` drops `com.sun.activation.jakarta.activation` — jooq's `jakarta.xml.bind-api` dependency became `optional` in 3.19, so amber's xml.bind-api falls back to 2.3.2 with no transitive activation jar. - `NOTICE-binary` regenerated via `bin/licensing/generate_notice_binary.py` (`io.r2dbc.r2dbc-spi 0.9.0 → 1.0.0` everywhere; amber also reflects the xml.bind-api / activation changes). ### Any related issues, documentation, discussions? Backport of apache/texera#6225. The path to eventually taking jOOQ 3.20+ (a project-wide Java 21 migration) is tracked in #6248. ### How was this PR tested? - Binary-license checks reproduced locally against each service's resolved runtime classpath on `release/v1.2`: `check_binary_deps.py --ignore-transitive-version jar --license-binary <svc>/LICENSE-binary <lib>` reports `OK: N jars match` for all six services, and `generate_notice_binary.py` output matches each committed `NOTICE-binary`. - CI on this PR exercises `build / amber`, `build / amber-integration` and `build / platform (<svc>)`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.8 [1M context]) --- No `release/*` label is added — this PR *is* the backport. -- 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]
