[
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.
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".
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.
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.
> 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)
