Joel Costigliola

After applying your suggestions, the build time is back to ~2min, @marchof feel free to close that issue and thanks again for the investigation.

Hi, AssertJ Core is experiencing the same issue I believe when we check contributors PR test coverage, ex: https://github.com/assertj/assertj-core/runs/4335956195?check_suite_focus=true. We experienced this issue for a while, the AssertJ codebase has...

@hcoles I have re-enabled pitest on assertj-core pull requests, the OOM is gone (yay!) but the build failed due to tests failing without mutation as per the logs of https://github.com/assertj/assertj-core/runs/7315662523?check_suite_focus=true....

Thanks for the quick reply, build succeeds now with the JVM args, looking forward to the next release.

Sure, @gervaisb are you keen to contribute this one ?

You can ask them here 🙂

The first option is fine, that is adding `protected abstract DateAssert assertionInvocationWithXmlGregorinaCalendarArg();` to `AbstractDateAssertWithDateArg_Test`. We should also rename `AbstractDateAssertWithDateArg_Test` to something like`AbstractDateAssertWithDifferentArgType_Test`.

@gervaisb please create a PR, that's make it easier to review your contribution.

@gervaisb After giving it some proper thoughts, I feel we need to clarify the proposed assertion, what is the concrete use case? The example shown comparing a `LocalDate` with a...

Fair enough, it is then important to clearly explain what the assertion behavior is regarding to time zones, especially when comparing local date/time with a XmlGregorianCalendar. I will add my...