[SUREFIRE-2234] Test name pattern '*' not recognised when using dot separators

**[Alexander Kriegisch](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=kriegaex)** opened **[SUREFIRE-2234](https://issues.apache.org/jira/browse/SUREFIRE-2234?redirect=false)** and commented

As discussed in this [users mailing list thread](https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl), something like

```none
mvn test -Dtest=dev.aspectj.*
```

does not work, while

```none
mvn test -Dtest=dev/aspectj/*
```

does. I.e., the matcher does not treat "/" path separators and "." package separators as equivalent, which IMO it should, also in more complex globbing patterns like

```none
dev.aspectj.**.*
```

Interestingly, as soon as there is a prefix to the asterisk, it starts working again, e.g.

```none
dev.aspectj.MyO*
```

_Sorry for using code blocks rather than inline code formatting, but Jira has problems with inline asterisk characters outside of code blocks._

One quick fix that fors for me locally, is

```none
--- a/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java (revision Staged)
+++ b/surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java (date 1707188275344)
@@ -339,7 +339,7 @@
private boolean matchClassPatter(String testClassFile) {
// @todo We have to use File.separator only because the MatchPatterns is using it internally - cannot
// override.
- String classPattern = ResolvedTest.this.classPattern;
+ String classPattern = ResolvedTest.this.classPattern.replace('.', '/');
if (separatorChar != '/') {
testClassFile = testClassFile.replace('/', separatorChar);
classPattern = classPattern.replace('/', separatorChar);
```

I did not thoroughly test it, but at least as a commiter you know where you can start looking.

The reason why this is a patch rather than a PR is that maybe this is the wrong place to replace the dots by slashes. Maybe, that should happen much earlier when parsing the patterns from the `test` parameter for the first time, if it is clear that they are no regex patterns. I think, the committers here know much better than I.

P.S.: If you are changing anything in that class, maybe you can take the change to correctly rename the two private methods `matchClassPatter` and `matchClassRegexPatter` to end with "n".

---

**Affects:** 3.2.5

Start in surefire-api/src/main/java/org/apache/maven/surefire/api/testset/ResolvedTest.java, especially the class-pattern matching entry point mentioned in the issue. Check the existing matching tests before deciding whether dot-to-slash normalization belongs there or earlier in pattern parsing. Done means dot-separated patterns such as dev.aspectj.* and dev.aspectj.**.* behave like their slash-separated forms without breaking regex patterns.

Written by the indexing model from the issue text.