[
https://issues.apache.org/jira/browse/SUREFIRE-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16684802#comment-16684802
]
ASF GitHub Bot commented on SUREFIRE-1309:
------------------------------------------
bturner commented on a change in pull request #138: SUREFIRE-1309: Clarifying
use of regular expressions for inclusion/exclusion
URL: https://github.com/apache/maven-surefire/pull/138#discussion_r232918244
##########
File path:
maven-surefire-plugin/src/site/apt/examples/inclusion-exclusion.apt.vm
##########
@@ -164,7 +164,16 @@ Inclusions and Exclusions of Tests
+---+
Note the syntax <<<%regex[expr]>>>, where <<<expr>>> is the actual
expression and the rest is just wrapping. Also
- note that regex matches are done over <<<*.class>>> files and not
<<<*.java>>> files.
+ note the following about the use of regular expressions:
+
+ * Regex matches are done over <<<*.class>>> files and not <<<*.java>>> files
+
+ * Regex matches are done over paths using slashes ("<<</>>>") and not
package names using dots ("<<<.>>>"), so the
+ "<<<.>>>" in <<<pkg.*Slow.*.class>>> is a regex metacharacter, which
happens to match any character, notably
+ the (forward) slashes ("<<</>>>") that make up the path. Slashes here
are <forward>, even on Windows
Review comment:
How will that approach work for being able to specify packages? When unit
tests run, we don't want to run anything with an `it` package at its root.
Having to specify fully qualified classnames for every single integration test
to not run in the Surefire configuration and then either specify every
integration test to run in Failsafe or every unit test not to run would be a
configuration nightmare.
We had been using `it/**` until we upgraded Surefire/Failsafe, but now that
has a behavior of automatically prepending `**/` to any pattern that doesn't
start with it, which ignores any class with an `it` package anywhere, rather
than just at the root. We switched to `%regex` to work around that change.
Does the new solution have some sort of wildcard syntax planned? And, if so,
will it have a way to say we don't want any "helpful" modifications to what we
configure?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Clarify %regex
> --------------
>
> Key: SUREFIRE-1309
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1309
> Project: Maven Surefire
> Issue Type: Bug
> Affects Versions: 2.19.1
> Environment: Probably any environment
> Reporter: Sander Verhagen
> Assignee: Tibor Digana
> Priority: Major
> Fix For: 2.20
>
>
> It would be good to clarify the {{%regex ...}} feature:
> 1. While it is said to be regular expression, it really is a {{regular
> expression + ".class"}} kind of thing. This does not work (while it is proper
> regex):
> {noformat}.+\.class{noformat} The following works (while it is not proper
> regex): {noformat}.+.class{noformat}
> 2. Clarify that one is supposed to match slashes between packages and class
> name, not periods. The following [current
> documentation|http://maven.apache.org/components/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html]
> doesn't clarify that by just using "{{.*}}":
> {noformat}!%regex[pkg.*Slow.*.class]{noformat}
> 3. Clarify what the expectations are in terms of escaping characters
> I just spend literally ten hours figuring out a complex regex, going into
> TeamCity (which by itself complicated the troubleshooting for me), and the
> documentation could have saved my butt, here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
