[ 
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Kriegisch updated SUREFIRE-2234:
------------------------------------------
    Description: 
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.

  was:
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.


> 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.



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

Reply via email to