[ 
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814621#comment-17814621
 ] 

Stanimir Stamenkov commented on SUREFIRE-2234:
----------------------------------------------

Quote from the current [plugin 
documentation|https://maven.apache.org/surefire/maven-surefire-plugin/examples/single-test.html#fully-qualified-class-name]:

{quote}
*Fully qualified class name*

As of Surefire Plugin 2.19.1, the syntax with fully qualified class names or 
packages can be used, e.g.:

{code:xml}
<test>my.package.???Test#testMethod, another.package.*</test>
{code}
{quote}

Notice: _syntax with fully qualified class names *or packages* can be used_, 
and the example: {{another.package.*}}

> Test name pattern '*' not recognised when using dot separators
> --------------------------------------------------------------
>
>                 Key: SUREFIRE-2234
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-2234
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: Maven Failsafe Plugin, Maven Surefire Plugin
>    Affects Versions: 3.2.5
>            Reporter: Alexander Kriegisch
>            Priority: Major
>
> As discussed in this [users mailing list 
> thread|https://lists.apache.org/thread/r52gobx5b92tlf7zkqr4k7hh4dntyxpl], 
> something like
> {code:none}
> mvn test -Dtest=dev.aspectj.*{code}
> does not work, while
> {code:none}
> mvn test -Dtest=dev/aspectj/*{code}
> 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
> {code:none}
> dev.aspectj.**.*{code}
> Interestingly, as soon as there is a prefix to the asterisk, it starts 
> working again, e.g.
> {code:none}
> dev.aspectj.MyO*{code}
> _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
> {code: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);
> {code}
> 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".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to