[3.27] Backport detection of Junit misconfiguration#53538
[3.27] Backport detection of Junit misconfiguration#53538holly-cummins wants to merge 3 commits intoquarkusio:3.27from
Conversation
quarkus-bot
bot
changed the title
|
/cc @aloubyansky (3.27), @gastaldi (3.27), @gsmet (3.27), @jmartisk (3.27), @rsvoboda (3.27) |
This comment has been minimized.
This comment has been minimized.
holly-cummins
force-pushed
the
backport-52350
branch
from
bbffde5 to
ca6bf7f
Compare
This comment has been minimized.
This comment has been minimized.
cescoffier
left a comment
cescoffier
left a comment
There was a problem hiding this comment.
just one commit (well a question actually)
|
|
||
| if (orderer.isEmpty() || !orderer.get().equals(DESIRED_CLASS_ORDERER.getName())) { | ||
| if (facadeLoader.hasMultipleClassLoaders()) { | ||
| String message = getFailureMessageForJUnitMisconfiguration(orderer); |
There was a problem hiding this comment.
The orderer, or the facade classloader? (It's a reasonable question for both.)
For the orderer, the JUnit API returns Optional, so I think I can assume it's not null, and I do the isEmpty check.
For FacadeClassLoader, I thought it couldn't be null, but looking more closely, we null it out in launcherSessionClosed and testPlanExecutionFinished. This usage is in launcherDiscoveryFinished. In any normal execution that would always be first, but the JUnit interaction with things like gradle does cause the order to go a bit wonky sometimes. I'll add a null check to be sure.
(We also use the FCL two lines earlier, but only in dev mode.)
2 participants
Backport of #52350.
See discussion.
I've kept most of the original code, but downgraded the exception to a warning.