ascheman opened a new pull request, #3392:
URL: https://github.com/apache/maven-surefire/pull/3392
Fixes #3345.
Maven 4 with `maven-compiler-plugin` 4.x compiles module-source-hierarchy
projects
(`<build><sources>` with one or more `<module>` entries, POM model 4.1.0) to
a nested
output layout — `target/classes/<module>/` and
`target/test-classes/<module>/` — and
writes a runtime handoff file
`target/test-classes/META-INF/maven/module-info-patch.args`
derived from `module-info-patch.maven` (the non-deprecated replacement for a
second
`module-info.java` in the test tree).
Surefire previously handled neither, so modular whitebox tests silently fell
back to the
classpath (module detection returned null) or failed test discovery
(`DirectoryScanner`
interpreted the module directory as a package prefix, producing doubled
FQCNs such as
`com.example.com.example.CalculatorTest`). The only workaround was a
per-module
`classesDirectory`/`testClassesDirectory`/`useModulePath`/`argLine`
configuration that
hardcodes a single module name.
### Changes
* `AbstractSurefireMojo`
* `findModuleDescriptor(...)` now also looks for `module-info.class` in
immediate
subdirectories of the build output (`target/classes/<module>/`), via a
new
`findNestedModuleDescriptor(...)` helper.
* `scanForTestClasses()` scans `target/test-classes/<module>/` when the
nested layout
is detected, instead of treating `<module>` as a package segment.
* The `--patch-module` source is the nested `target/test-classes/<module>`
directory
when present.
* `ModularClasspathForkConfiguration`
* `createArgsFile(...)` now reads the compiler-generated
`module-info-patch.args`
(searched in the patch directory and its parent) and passes its
directives (e.g.
`--add-exports`) through to the forked JVM argfile.
* `--add-reads`/`--add-modules` lines from the handoff file are
intentionally skipped
(both one-line and two-line argfile form): they may reference named
modules that
surefire places on the classpath rather than the module path; surefire
keeps
generating `--add-reads <module>=ALL-UNNAMED` and `--add-modules
ALL-MODULE-PATH`
itself, plus `--add-opens` for test packages (JUnit reflection;
`module-info-patch.maven`
cannot express `ALL-UNNAMED` opens).
* `surefire-its` fixture: `MavenLauncher` defaults to forked JVM when the
Maven under
test is 4.x — `Embedded3xLauncher` only supports the Maven 3 `MavenCli`
entry point,
so embedded mode cannot launch Maven 4 at all.
### Tests
* Unit tests: nested-descriptor detection (flat layout unaffected, empty
dir, nested hit)
in `AbstractSurefireMojoJava7PlusTest`; handoff-file consumption, fallback
without the
file, and a regression test that a directive directly following a skipped
one-line
option is not swallowed, in `ModularClasspathForkConfigurationTest`.
* New ITs:
* `ModulePathWhiteboxIT` — classic single-module layout, whitebox tests
patched into
the module via `--patch-module`; runs under Maven 3 and Maven 4.
* `Surefire3345ModuleSourceHierarchyIT` — model-4.1.0 module source
hierarchy
with `module-info-patch.maven`, compiler 4.0.0-beta-4; skips itself
under Maven 3
(assumption on `maven-api-core` in `${maven.home}/lib`).
### Verification matrix (local, JDK 17.0.18-tem, macOS)
| Maven | classic IT | module-source-hierarchy IT |
|---|---|---|
| 3.9.16 | pass | skip (assumption) |
| 3.10.0-rc-1 | pass | skip (assumption) |
| 4.0.0-rc-5 | pass | pass |
| 4.0.x-SNAPSHOT (e1f82346b2, rc-6 candidate) | pass | pass |
Full `maven-surefire-common` unit suite: 848 tests, 0 failures (Maven
3.10.0-rc-1 build).
### Scope notes
* This PR covers **one Java module per POM** (the common case, and the
zero-config goal
of #3345). Projects declaring several modules in one POM still need
per-module
executions; multi-module-in-one-execution is follow-up work (see #3345
discussion).
* Verified against a real 3-module module-source-hierarchy component (602
tests):
the existing per-module `classesDirectory`/`testClassesDirectory`
workaround behaves
identically with this patch (no regression). A *zero-config* run on such a
multi-module
component now fails loudly at the JPMS boot layer (`FindException` for
module
dependencies that surefire places on the classpath — #3090) instead of
silently
running 0 tests; the multi-module follow-up plus #3090 are needed before
zero-config
works there.
* Known adjacent issues intentionally not addressed here: #3088
(SUREFIRE-1765,
`target/test-classes` additionally on the classpath), #3090
(SUREFIRE-1755),
#3040 (SUREFIRE-1811).
* The new module-source-hierarchy IT is skipped on the current Maven 3 CI
matrix; it ran
for real locally against 4.0.0-rc-5 and the current 4.0.x snapshot (see
matrix). Once
#3352 enables a Maven 4 CI job, it will run there too.
---
Following this checklist to help us incorporate your contribution quickly
and easily:
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean install` to make sure basic checks pass. A more
thorough check will be performed on your pull request automatically.
- [x] You have run the integration tests successfully (the new ITs plus the
matrix above; the full suite runs in CI).
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
--
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]
