Vladimir Sitnikov

Well, I would say AssertJ users (developers?) should be pretty much familiar with diffs. Even GitHub UI shows that diff if you switch to "unified diff view"

Here's another case for diff output: https://truth.dev/comparison#failure-messages. Note how diff output in XML makes it much easier to tell the difference.

I agree `withFailMessage` might indeed confuse people a lot, and I think rare when `withFailMessage` is the right choice over `as`. For instance, see https://github.com/openrewrite/rewrite-testing-frameworks/issues/234 where they currently use `withFailMessage`...

> Convert assertj/assertj-parent-pom to be a submodule Is the submodule really needed? Would it work if it is a regular folder in assertj/assertj repo?

>Would a NOTICE file with the following statement be enough to properly express the work attribution? One more thing would be adding the following to the source redistribution of AssertJ...

>I don't see the chance to have such dependency. How can you be so sure? Do you test such a configuration? Here's a sample from TestNG project where I fix...

I'm sorry to disappoint you, however, there you go: https://github.com/vlsi/assertj-core/actions/runs/2501500063 1) hashcode-induced compilation failure? https://github.com/vlsi/assertj-core/runs/6897737252?check_suite_focus=true#step:4:49 2) locale-dependent failure in assertj: https://github.com/vlsi/assertj-core/runs/6897737252?check_suite_focus=true

I am truly surprised that a test-related library declines suggestions that increase test coverage and require zero effort on maintenance.

> the others are compilation errors which I would disagree here. The CI matrix discovered a true bug in assertj https://github.com/assertj/assertj-core/issues/2663.

>Recently I discovered that Maven wrapper script mvnw can work without wrapper jar There's a significant security issue hidden in `mvnw`: it does not validate the received jar. So it...