ZiadMarey opened a new issue, #3488: URL: https://github.com/apache/maven-surefire/issues/3488
## Affected version 3.6.0 (regression — works correctly on 3.5.6) ## Bug description `maven-surefire-plugin`/`maven-failsafe-plugin` 3.6.0's JUnit Platform provider silently fails to discover **any** test in a module whose package name contains the substring `java` as a whole path segment (e.g. `com.example.its.java.SomeIT`) — but only when the module's project layout matches a specific combination described below. The build reports `BUILD SUCCESS` with `Tests run: 0, Failures: 0, Errors: 0, Skipped: 0` — no error, no warning, no exception anywhere in `-X` debug output. The affected class's name never even appears in the log (no `Running com.example...` line is printed, meaning discovery drops it before execution is attempted at all). ### Reproduction We confirmed this with a clean, controlled A/B test in our own multi-module project: - A trivial test class `com.example.its.probe.ProbeIT` (package **without** "java") → discovered and runs correctly (`Tests run: 1`). - The exact same trivial class, only its package renamed to `com.example.its.javaprobe.ProbeIT` (package **containing** "java" as a substring) → `Tests run: 0`, never discovered, in the same module/build/classpath. - Repeated with a real, substantive, pre-existing test class (not a toy example): identical file, only the package changed from `...its.java` to `...its.probe` — same result. In `...its.java` it's never discovered; the identical file relocated to `...its.probe` is discovered and actually runs. Downgrading only `maven-surefire-plugin`/`maven-failsafe-plugin` to `3.5.6` for the affected module (via a module-level plugin version override, `<pluginManagement>` untouched) immediately fixes discovery, with no other change. ### What we ruled out Since this symptom looks similar to #3466 (fixed) / #3474 (still open), we suspected the same "class name matched against a file-path-style pattern" bug class. However: - Our project's failsafe config does not use `%regex[...]` includes anywhere. - We tried to reproduce the divergence by calling the real compiled 3.6.0 classes directly (`TestListResolver.shouldRun`, and a faithful port of `JUnitPlatformProvider.matchClassName` using the real `SelectorUtils`) with our exact class names — neither showed any difference in behavior between a "java"-containing package and one without, in isolation. So while the *symptom* matches the known bug class, we were not able to pin down the exact line responsible, and this may be a distinct (or interacting) trigger condition. - We also ruled out (by direct testing): module-specific dependencies, base class hierarchies, `excludedGroups`/`groups` configuration, CI runner type, Maven cache state, and git submodule initialization steps — none of these affect the reproduction. ### Environment - `maven-surefire-plugin` / `maven-failsafe-plugin`: 3.6.0 - JUnit Jupiter: 5.14.4 / JUnit Platform: 1.14.4 - JDK 21 - Reproduced on both Windows and Linux (GitHub Actions `ubuntu`-based runners) - Multi-module Maven reactor (the affected module is one of several sibling modules with an otherwise near-identical layout; only the one whose package contains "java" is affected) Happy to provide a minimal standalone reproducer repository if useful. -- 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]
