3.6.0 regression: `<includes>` pattern with a package directory (e.g. `com/example/it/**/*IT.java`) runs zero tests

[orion0616]

Affected version

3.6.0 (also 3.6.0-M1). Works with 3.5.6.

Bug description

Minimal reproducer: https://github.com/orion0616/surefire-includes-repro (one Jupiter test com.example.it.SampleIT, failsafe configured with <include>com/example/it/**/*IT.java</include>)

mvn verify -Dsurefire.version=3.5.6   # Tests run: 1
mvn verify -Dsurefire.version=3.6.0   # Tests run: 0, BUILD SUCCESS

<include>	3.5.6	3.6.0
com/example/it/**/*IT.java	1	0
**/it/**/*IT.java	1	0
%regex[.*SampleIT\.class]	1	0
**/*IT.java	1	1
com/example/it/*IT.java	1	1

With -X, 3.6.0 still logs Tests to run: [com.example.it.SampleIT] and starts the fork, so the class is dropped inside the fork, not by the scanner. Same result with JUnit 5.14.1 and 6.0.3. Both pattern forms are documented as supported (the docs use pkg/**/*Fast*.java as an example, and say %regex[...] is matched against .class paths with slashes): https://maven.apache.org/surefire/maven-failsafe-plugin/examples/inclusion-exclusion.html

This looks like the provider-level ClassNameFilter added in #3179 (JUnitPlatformProvider#newFilters, the same area as #3446). The scanner-style patterns are matched against dotted class names: the / to . replacement is commented out, and after the fallback replacement in matchClassName an intermediate ** requires a literal ., so com.example.it.**.*IT never matches com.example.it.SampleIT. %regex[...] is passed to ClassNameFilter.includeClassNamePatterns, i.e. applied to class names instead of class file paths. Matching the class file name the way the scanner does, e.g. TestListResolver.shouldRun(TestListResolver.toClassFileName(className), null), would keep both filters consistent.

In our project this silently turned 185 integration tests into 0 with a green build, since failIfNoTests defaults to false.

I have a fix with unit and integration tests in progress and will open a PR shortly.

[XN137]

i think we are hitting the same issue.
just to add another data point:

      <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <forkCount>1</forkCount>
          <includes>
            <include>**/CompanyTestSuite.class</include>
          </includes>
        </configuration>
      </plugin>

this seems to have stopped finding any tests after upgrading to 3.6.0

[slachiewicz]

You may be affected by #3453

[orion0616]

@slachiewicz thanks for looking. I believe this one takes a different path than #3453: it happens with forkCount=1 and no toolchain, the plugin still logs Tests to run: [com.example.it.SampleIT] and starts the fork, and the class is then rejected inside the fork by the ClassNameFilter in JUnitPlatformProvider#newFilters(). I have a proposed fix in #3466, happy to adjust it if you see it differently.

@XN137 looks like the same root cause: **/SampleIT.class and a bare SampleIT.class reproduce with the minimal project (1 test with 3.5.6, 0 with 3.6.0), and both run again with a build of #3466.

[olamy]

You may be affected by #3453

I do think there is nothing related here. the other case is a corner case when using toolchain (different jvm from main Maven process compared to the forked process

[OliverTetzTT]

We encountered a similar issue in our configuration. In our case it affects the maven-failsafe-plugin

<includes>
   <include>**/*ST.java</include>
</includes>

I wanted to extend the observations by:

<failIfNoTests>true</failIfNoTests>

did also not work in the 3.6.0 version.

The corresponding output:

[INFO] --- failsafe:3.6.0:integration-test (system-test) @ web ---
[INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO] 
[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  4.169 s
[INFO] Finished at: 2026-09-09T13:29:31+02:00
[INFO] ------------------------------------------------------------------------

In the 3.5.6 (after manipulating to a non-matching include pattern) I got a BUILD FAILURE as expected.