Created attachment 824641 [details]
=dev-java/assertj-core-3.10.0 fails its test phase on one of my two machines, after passing on the other machine five days ago.
The specific tests that failed were as follows (extracted from the build log):
And for each of these the abbreviated stack trace looks the same:
Can't find any field or property with name 'comparatorsByType'.
Error when introspecting properties was :
- No public getter for property 'comparatorsByType' in org.assertj.core.api.ListAssert
Error when introspecting fields was :
- Unable to obtain the value of the field <'comparatorsByType'> from <org.assertj.core.api.ListAssert@1>, check that field is public.
... 33 trimmed
Caused by: org.assertj.core.util.introspection.IntrospectionError: Unable to obtain the value of the field <'comparatorsByType'> from <org.assertj.core.api.ListAssert@1>, check that field is public.
... 37 more
Caused by: java.lang.IllegalAccessException: can not accesscomparatorsByType because it is not public
... 39 more
Created attachment 824643 [details]
Belatedly Googling, I found https://github.com/assertj/assertj/issues/1338, which looks at first glance to be this exact issue, and claims that it's fixed by https://github.com/assertj/assertj/commit/905cfdeeb9b01f35bab76377792eaca121146835, but that commit looks (by comparing the patch to the source code unpacked in $S) to already be part of this version.
(In reply to Jonathan Lovelace from comment #2)
Thanks for reporting and excellent analysis.
However I cannot reproduce those errors.
I get them consistently on that one machine (which is a ~2010 MacBook), but my other machine passes all the tests without error (I just checked it again). If there's some way to run the tests completely serially (like MAKEOPTS=-j1), that might either work around the issue or make it reproducible, but I'm not aware of any way to do so.
I did a little more cursory searching through the upstream Git repository, and found some other commits related to making tests more robust against conflicting temporary changes to configuration, but all the ones I remember finding postdated the modularization of the code and so couldn't be easily adapted to apply to this release.
(In reply to Jonathan Lovelace from comment #4)
> I get them consistently on that one machine (which is a ~2010 MacBook), but
> my other machine passes all the tests without error (I just checked it
> again). If there's some way to run the tests completely serially [...]
Separating tests could be done by calling 'java-pkg-simple_src_test' for each test as is done in https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/reload4j/reload4j-1.2.22.ebuild.