Follow-up to #3345 / #3392, which add support for the Maven 4 Module Source Hierarchy with ONE Java module per POM.
Maven 4 allows declaring several modules in one POM (<build><sources> with multiple <module> entries, POM model 4.1.0). maven-compiler-plugin 4.x compiles them to target/classes/<module-1>/, target/classes/<module-2>/, … and test classes to target/test-classes/<module-N>/.
With the single-module support from #3392, surefire on such a project:
- detects only the FIRST nested module descriptor,
- scans only that module's nested test directory,
- decides classpath-vs-module-path placement of dependencies with that single module descriptor via
LocationManager.resolvePaths(...) — dependencies that only sibling modules require stay on the classpath, and the forked JVM fails at boot:
java.lang.module.FindException: Module <dep> not found, required by <sibling-module>
(all nested modules resolve into the boot layer because target/classes is on the module path as a directory of modules, together with --add-modules ALL-MODULE-PATH),
- patches and opens only the first module.
Reproduced with a real-world 3-module component (jakarta.json/jsonb implementation, 602 tests): zero-config surefire fails with the FindException above; the only working setup is one surefire execution per module with explicit classesDirectory/testClassesDirectory/additionalClasspathElements.
Expected: one mvn test execution runs the tests of ALL modules — each module patched with its own target/test-classes/<module>/, each opened for reflection, and the dependency split computed as the union over all module descriptors.
A PR implementing this (stacked on #3392) follows immediately.
cc @desruisseaux — this is the multi-module follow-up announced in #3345.
Follow-up to #3345 / #3392, which add support for the Maven 4 Module Source Hierarchy with ONE Java module per POM.
Maven 4 allows declaring several modules in one POM (
<build><sources>with multiple<module>entries, POM model 4.1.0). maven-compiler-plugin 4.x compiles them totarget/classes/<module-1>/,target/classes/<module-2>/, … and test classes totarget/test-classes/<module-N>/.With the single-module support from #3392, surefire on such a project:
LocationManager.resolvePaths(...)— dependencies that only sibling modulesrequirestay on the classpath, and the forked JVM fails at boot:java.lang.module.FindException: Module <dep> not found, required by <sibling-module>(all nested modules resolve into the boot layer because
target/classesis on the module path as a directory of modules, together with--add-modules ALL-MODULE-PATH),Reproduced with a real-world 3-module component (jakarta.json/jsonb implementation, 602 tests): zero-config surefire fails with the
FindExceptionabove; the only working setup is one surefire execution per module with explicitclassesDirectory/testClassesDirectory/additionalClasspathElements.Expected: one
mvn testexecution runs the tests of ALL modules — each module patched with its owntarget/test-classes/<module>/, each opened for reflection, and the dependency split computed as the union over all module descriptors.A PR implementing this (stacked on #3392) follows immediately.
cc @desruisseaux — this is the multi-module follow-up announced in #3345.