[
https://issues.apache.org/jira/browse/IGNITE-28893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-28893:
----------------------------------------
Labels: ignite-2 ise (was: )
> Calcite. Missing joou runtime dependency halts node startup in release
> package and C++ tests
> --------------------------------------------------------------------------------------------
>
> Key: IGNITE-28893
> URL: https://issues.apache.org/jira/browse/IGNITE-28893
> Project: Ignite
> Issue Type: Task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: ignite-2, ise
> Fix For: 2.19
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The Calcite upgrade from 1.40 to 1.42 changed only the version properties in
> modules/calcite/pom.xml.
> However, calcite-core 1.42 declares a new runtime dependency,
> org.jooq:joou-java-6, which
> calcite-core 1.40 did not have. It was not added to the module's dependency
> list.
> Why that matters:
> The copy-libs execution of maven-dependency-plugin in parent/pom.xml copies
> only DIRECT dependencies
> into target/libs (excludeTransitive is true). This is 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. The assembly descriptor
> (assembly/dependencies-apache-ignite.xml) maps each
> optional module's target/libs into libs/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.
> Effect:
> A node with the Calcite query engine enabled 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
> Because StopNodeOrHaltFailureHandler halts the JVM from inside the hosting
> process, the C++ test
> binary that started the node is killed along with it, and its remaining tests
> never run.
> In CI this shows up in the Platform C++ CMake suites: the only C++
> configuration that enables the
> Calcite engine is odbc-test/config/queries-default.xml, so the ODBC binary
> dies at its first
> node-starting test (ConnectionTestSuite: TestConnectionRestore, which boots
> queries-test.xml). The
> suite reports 595 tests instead of 1046 with zero failures - core-test 458
> and thin-client-test 130
> complete, odbc-test contributes only 7 - and the "test count dropped" guard
> turns the suite red.
> Java test suites are unaffected because Surefire resolves the full transitive
> classpath from Maven.
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
