[jira] [Commented] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814625#comment-17814625
]
Stanimir Stamenkov commented on SUREFIRE-2234:
--
{quote}
Interestingly, as soon as there is a prefix to the asterisk, it starts working
again, e.g.
{code:none}dev.aspectj.MyO*{code}
{quote}
I've also tried the following appear to work (around):
{code:none}dev.aspectj.?*{code}
> 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)
[jira] [Commented] (SUREFIRE-2234) Test name pattern '*' not recognised when using dot separators
[
https://issues.apache.org/jira/browse/SUREFIRE-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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}
my.package.???Test#testMethod, another.package.*
{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)
