[jira] [Updated] (IGNITE-28894) C++: thin-client nested modules are missing from the dev-mode classpath

["Ignite TC Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-28894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ignite TC Bot updated IGNITE-28894:
-----------------------------------
    Ignite Flags:   (was: Release Notes Required)

> C++: thin-client nested modules are missing from the dev-mode classpath
> -----------------------------------------------------------------------
>
>                 Key: IGNITE-28894
>                 URL: https://issues.apache.org/jira/browse/IGNITE-28894
>             Project: Ignite
>          Issue Type: Task
>            Reporter: Anton Vinogradov
>            Assignee: Anton Vinogradov
>            Priority: Major
>             Fix For: 2.19
>
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> CreateIgniteHomeClasspath() (used when IGNITE_NATIVE_TEST_CLASSPATH=true, i.e. C++ tests run against an exploded dev build) scans modules/ only one level deep: for every direct child it calls ClasspathExploded(child, false), so nested maven modules are never visited.
> modules/thin-client is not a maven module itself (it has no pom.xml) — it is a grouping directory holding thin-client/api and thin-client/impl. As a result neither their target/classes nor their target/libs end up on the classpath of a node started from C++.
> These classes cannot arrive any other way: copy-dependencies in parent/pom.xml sets <excludeGroupIds>${project.groupId}</excludeGroupIds>, so ignite artifacts are never copied into target/libs.
> jdeps confirms real bytecode references from ignite-core into the thin client:
>   * org.apache.ignite.Ignition -> IgniteClient, ClientException, TcpIgniteClient
>   * management commands (DeactivateCommand, SetStateCommand, StateCommand, WarmUpStopCommand, CommandUtils) -> ClientCluster, IgniteClient
> They are resolved lazily, so a node currently starts fine (verified with both the default config and the cache-test.xml used by the C++ core tests). But any path that reaches Ignition.startClient() or a management command from the C++-hosted JVM fails with NoClassDefFoundError. The hole is latent, not yet observable in the existing C++ suite.
> The same problem was already solved for modules/binary when it was split into api/impl: CreateIgniteHomeClasspath() carries an explicit recursive special case for that directory — ClasspathExploded(home + "/modules/binary", true). Moving the thin client into nested modules did not add the matching line; the C++ side was not touched at all.
> Fix: mirror the binary special case for modules/thin-client in both
>   * modules/platforms/cpp/core/src/jni/os/linux/utils.cpp
>   * modules/platforms/cpp/core/src/jni/os/win/utils.cpp
> A generic two-level scan is deliberately avoided: it would additionally pull extdata/* (p2p / URI-deployment test data that is intentionally kept off the classpath), platforms/dotnet and web/*-test into the dev node classpath.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)