Stefano Cordio

As mentioned in https://github.com/assertj/assertj-core/issues/2357#issuecomment-1181387367, we will analyze how to better support these use cases in version 4 as they will most likely require breaking changes.

@sroeper @SickDawn before moving forward with additional changes, I suggest providing feedback to https://github.com/assertj/assertj-core/issues/2341#issuecomment-1108291520.

Hi @schrek1, at the moment the team tends to favor the `getParameters()` approach I was describing in https://github.com/assertj/assertj-core/issues/2153#issuecomment-801949339, mainly to avoid duplications and reduce maintenance. Would this also fit you?

Memo for merging: @sarajuhosova co-authored #2500.

> Using the same with a `PathMatcher` succeeds. > > ``` > assertThat(dir.getFileSystem().getPathMatcher("glob:test-[0-9a-f]*.txt").matches(Path.of("test-6e672c4ba0be4f0886d434125a0d062c.txt"))).isTrue(); > assertThat(dir.getFileSystem().getPathMatcher("regex:test-[0-9a-f]+\\.txt").matches(Path.of("test-6e672c4ba0be4f0886d434125a0d062c.txt"))).isTrue(); > ``` Just as a note, the example with the `PathMatcher` is not the same...

Thanks for the details @sephiroth-j, I agree we could make it more intuitive paying the price of a breaking change. I'm investigating a possible solution to get the behavior you...

As per internal discussion, all the error messages should display the filenames only. Also, with #2338 we will make sure that `isDirectoryRecursivelyContaining(String)` follows the same behavior, but this will be...

@sephiroth-j we will postpone this change to 3.22.0 as we would like to think a bit more about the behavior for both `isDirectoryContaining(String)` and `isDirectoryRecursivelyContaining(String)`.

> Looks like an unrelated random test failure to me, re-running the checks should fix it. No worries about that, we have a few flaky tests around. As you can...

Hi @StefanBratanov, the team bandwidth is currently limited and it may take some time before we can look into it. Thanks for your patience 🙏