anton-vinogradov opened a new pull request, #13373:
URL: https://github.com/apache/ignite/pull/13373

   `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 (no `pom.xml`) — it is a 
grouping directory holding `thin-client/api` and `thin-client/impl`. Neither 
their `target/classes` nor their `target/libs` end up on the classpath of a 
node started from C++, and they 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 reaching `Ignition.startClient()` or a management command from the 
C++-hosted JVM fails with `NoClassDefFoundError`. The hole is latent — it is 
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.
   
   This change mirrors the `binary` special case for `modules/thin-client` in 
both `linux/utils.cpp` and `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 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]

Reply via email to