anton-vinogradov opened a new pull request, #13372:
URL: https://github.com/apache/ignite/pull/13372
## Symptom
The `Platform C++ CMake` suites report **595 tests instead of 1046, with
zero failures**. The TeamCity "test count dropped" guard turns the suite red
without a single failed test, which in turn poisons PR verdicts. Most PRs do
not see it because their chains reuse older C++ results.
## Root cause
The Calcite upgrade from 1.40 to 1.42 changed only the version properties in
`modules/calcite/pom.xml`. But `calcite-core` 1.42 declares a **new runtime
dependency**, `org.jooq:joou-java-6:0.9.5`, which 1.40 did not have, and it was
not added to the module's dependency list.
That matters because the `copy-libs` execution of `maven-dependency-plugin`
in `parent/pom.xml` copies only **direct** dependencies into `target/libs`
(`excludeTransitive` is `true`). This is exactly why `modules/calcite/pom.xml`
already declares Calcite's runtime dependencies explicitly — guava,
failureaccess, janino, avatica-core, jackson, json-path, reflections. `joou`
was not declared, so it never lands in `modules/calcite/target/libs`.
Two consumers are built from `target/libs`:
1. **The release package.** `assembly/dependencies-apache-ignite.xml` maps
each optional module's `target/libs` into `optional/${module.artifactId}`, so
`libs/optional/ignite-calcite` ships without joou.
2. **The exploded classpath of the embedded dev node**, assembled by
`CreateIgniteHomeClasspath()` in
`modules/platforms/cpp/core/src/jni/os/{linux,win}/utils.cpp`, which appends
each module's `target/libs` jars. This is the classpath the C++ tests boot
their JVM node with.
A node with the Calcite engine enabled therefore dies during startup:
```
java.lang.NoClassDefFoundError: org/joou/ULong
Critical system error detected ... failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION,
err=java.lang.NoClassDefFoundError: org/joou/ULong]
JVM will be halted immediately due to the failure
```
`StopNodeOrHaltFailureHandler` halts the JVM **from inside the hosting
process**, so the C++ test binary that started the node is killed along with it
and its remaining tests never run.
The only C++ configuration that enables the Calcite engine is
`odbc-test/config/queries-default.xml`. That is why exactly one binary dies:
the ODBC one, at its first node-starting test (`ConnectionTestSuite:
TestConnectionRestore`, which boots `queries-test.xml`). The suite's 595 tests
break down as core-test 458 + thin-client-test 130 + odbc-test **7**.
Java suites are unaffected because Surefire resolves the full transitive
classpath from Maven — only the `target/libs`-based layouts are broken.
## Fix
Declare `org.jooq:joou-java-6` explicitly in `modules/calcite/pom.xml`, so
it is copied into `target/libs` and reaches both the release package and the
exploded test classpath.
## What was verified vs. inferred
**Verified locally:**
- `calcite-core` 1.40.0 has no joou; 1.42.0 declares `joou-java-6:0.9.5`
with `scope=runtime`.
- Before the fix `modules/calcite/target/libs` contains 19 jars, joou
absent; after the fix 20 jars, `joou-java-6-0.9.5.jar` present.
- Booting a node from the ODBC suite's own `queries-test.xml` on an exploded
classpath **without** joou reproduces `NoClassDefFoundError: org/joou/ULong` →
critical system error → JVM halt (exit 130). With joou on the classpath the
same node starts normally.
**Verified from the CI build:** the failing build's test list (core-test
458, thin-client-test 130, odbc-test 7) and the build log, which contains the
`NoClassDefFoundError: org/joou/UByte` stack and the subsequent halt. (The
class differs from the local run — `UByte` vs `ULong` — because the first
reflective touch of the missing library varies by code path; the library and
the failure are the same.)
**Not verified:** the C++ toolchain was not built locally, so the death of
the boost binary itself was observed only in the CI log, not reproduced on my
machine. Windows behaviour is inferred from the Linux run plus the identical
packaging path.
**Out of scope:** 26 further transitive runtime dependencies of calcite-core
(proj4j, avatica remote HTTP, snakeyaml, …) are likewise absent from
`target/libs`. They have always been absent and are not reached at runtime;
only joou became newly required. Worth keeping in mind on the next
Calcite/Avatica bump.
cc @zstan (Calcite upgrade), @timoninmaxim (the `target/libs` /
exploded-classpath machinery)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
