Hi all, I encountered a build issue recently that no one in the team has seen, which I believe it's caused by multi-thread racing but I can't prove it tbh.
Maven version tested: 3.6.3 & 3.9.1 Java: open-jdk 11 Our project contains multiple modules and <modules> is declared in parent pom. And let's say if A module depends on B module, then module B is not explicitly added into the A's pom file. When multi-thread is turned on (with parameter `-T 1C`,1 thread per core, Apple M2 silicon), there is a high chance of compilation error (usually saying class not found). After turning off multi-threading, `mvn clean install` is ok but still `mvn dependency:analyze` would always fail. However, the issue is completely gone once I manually listed B as a dependency in A's pom file. Note, the actual dependency graph is a bit complicated so you can imagine there are multiple A-B, A-C, B-C etc pairs. I have read the page regarding how reactor sorting works ( https://maven.apache.org/guides/mini/guide-multiple-modules.html#reactor-sorting) so it looks like our current project uses rule 5 only. But here are the things I don't know for sure: - if reactor sorting only uses rule5 only, does it mean the build order would strictly follow the module declaring order in <modules>? If that's the case, it seems the multi-thread race conditions shouldn't happen. Is my understanding correct? - How does dependency:analyze work? Is there documentation I can read? This always fail and seems it's not related to the `-T 1C` parameter. - What's the preferred way to manage multi-module dependencies? Is it better to strictly declare them whenever using the dependencies (rule 1) or this is no best practice but only different options? Thanks Joe
