Properly allow mixing @QuarkusTest and @QuarkusMainTest

[geoand]

This is done by "restarting" the application when one test type follows the other.

Fixes: #28486

[ebullient]

Should we change "in the same run" to in the same package? I have a feeling the package boundary will work, and that suggests a solution.

Does run otherwise mean build phase?

[geoand]

Should we change "in the same run" to in the same package? I have a feeling the package boundary will work, and that suggests a solution.

I am not sure why it worked in your case, it should not really make a difference.

Does run otherwise mean build phase?

It generally means Maven surefire execution, or whatever the Gradle equivalent is :)

[quarkus-bot]

Failing Jobs - Building f997c67

Status	Name	Step	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 11
✔️	JVM Tests - JDK 17
✖	JVM Tests - JDK 17 MacOS M1	Set up runner	⚠️ Check →	Logs	Raw logs
✔️	JVM Tests - JDK 18

[ebullient]

Should we change "in the same run" to in the same package? I have a feeling the package boundary will work, and that suggests a solution.

I am not sure why it worked in your case, it should not really make a difference.

Does run otherwise mean build phase?

It generally means Maven surefire execution, or whatever the Gradle equivalent is :)

Right.. but is that accurate? That is one hell of a constraint (that you have to go through the work to make a whole 'nother execution in the pom.xml.. yuck).

What is the example where that would actually be required?

[geoand]

Right.. but is that accurate? That is one hell of a constraint (that you have to go through the work to make a whole 'nother execution in the pom.xml.. yuck).

That constraint has now been lifted :)

[ebullient]

That constraint has now been lifted :)

For this case, yes, but the condition test (with the problematic/unclear wording) is still there. What theoretical case is it covering? And would putting that in a different package solve that case (not having x and y in the same package is something more understandable than having to create a new surefire test execution? and if it isn't, then we should say 'surefire test execution' instead of 'run')

[geoand]

The condition has been amended to allow mixing these two types of tests.

Changing the package should not make a difference, although the reason it did is probably test order

[geoand]

What theoretical case is it covering?

See #27247

[ebullient]

I feel like we're talking past each other. I get the original problem that instigated the change, so what is now left as the else path.. and why isn't the fix that you made for this case applicable to the general case? Are we just waiting for the next failure for some other conflict between types because we aren't sure?

[geoand]

I'm trying to play it safe as I'm not totally convinced that all tests can play with all other tests