Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/589
@geomacy @neykov I'm getting too bogged down in the possibilities here, and
can't decide what's best!
I looked at automatically setting MULTILINE and DOTALL, but I think it's
then impossible to turn them off again for the user (as demonstrated by the
code below - the args to "compile" seem to take precedence over the `(?!s)` in
the pattern, but I couldn't find docs that would say definitively if that's the
case):
```
@Test
public void tmp() {
String expected = "(?!s).*line2.*";
String actual = "line1\nline2\n";
Pattern matchesPattern = Pattern.compile(expected, Pattern.DOTALL |
Pattern.MULTILINE);
Asserts.assertFalse(matchesPattern.matcher(actual.toString()).matches());
}
```
I therefore lean towards @geomacy's suggestion of leaving `matches` as-is,
and just documenting it.
However, I still lean towards adding `containsMatch`, which uses `find()`
*without* setting DOTALL or MULTILINE. I think it's reasonable to support all
of `contains`, `matches` and `containsMatch`, with the behaviour being
"obvious" to the user.
The non-obvious bit is that `matches` (and `containsMatch`) will default to
not DOTALL and not MULTILINE. Unfortunately neither way round would be
intuitive to everyone [1].
I'm therefore going to update the PR as described above!
[1] See section "Using ^ and $ as Start of Line and End of Line Anchors" of
http://www.regular-expressions.info/anchors.html, which talks about different
behaviour in different systems - it says that for almost all programming
languages and libraries, you have to explicitly enable multiline/dotall
yourself.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
