Allow extensions and extensions-jvm module tests to be run with alternate BOMs

[JinyuChen97]

Migrate QuarkusUnitTest-based tests that cover interoperability with Quarkus or non-Camel transitives out of the deployment modules and into their respective integration-tests modules using @QuarkusTest + TestProfile, so that they can be exercised when running the test suite against alternate Quarkus platform BOMs.

quartz (integration-tests/quartz):

Migrated:

• QuartzNotAutowiredTest
• QuartzNoQuarkusSchedulerAutowiredTest
• QuartzQuarkusSchedulerAutowiredTest
• QuartzQuarkusSchedulerNotAutowiredTest
• QuartzQuarkusCustomSchedulerAutowiredTest
• QuartzQuarkusSchedulerAutowiredWithSchedulerBeanTest

Not migrated:

• QuartzQuarkusSchedulerAmbiguousAutowiredTest
  (startup failure asserted via setExpectedException, no @QuarkusTest equivalent)

[jamesnetherton]

I've not done a deep review (yet), but I think you could simplify things a lot and just copy the tests as-is and add quarkus-junit-internal to the relevant integration-test module(s) (it may actually already be there transitively).

The problem with reimplementing the tests as @QuarkusTest is that you need a bunch of extra test profiles. And that slows things down because you end up restarting the app multiple times.

[JinyuChen97]

I've not done a deep review (yet), but I think you could simplify things a lot and just copy the tests as-is and add quarkus-junit-internal to the relevant integration-test module(s) (it may actually already be there transitively).

The problem with reimplementing the tests as @QuarkusTest is that you need a bunch of extra test profiles. And that slows things down because you end up restarting the app multiple times.

Thanks for the feedback, this is also my concern as well. Since each of migrated test has slightly different application properties, so they can't easily share the same profile. But I'm also wondering if we migrate them as QuarkusUnitTest, for each QuarkusUnitTest, they will start a new quarkus instance, will that also put pressure on CI maintain?

I actually tried moving the QuarkusUnitTest tests directly into integration-test modules, there is an issue when running QuarkusUnitTest and QuarkusTest together caused some conflict exception in quarkus test framework, I need to modify the maven-surefire-plugin to change the execution order of QuarkusUnitTest and QuarkusTest to let QuarkusUnitTest run first, then QuarkusTest to fix this error.

Thanks for any suggestion.

[jamesnetherton]

I actually tried moving the QuarkusUnitTest tests directly into integration-test modules, there is an issue when running QuarkusUnitTest and QuarkusTest together caused some conflict exception in quarkus test framework, I need to modify the maven-surefire-plugin to change the execution order of QuarkusUnitTest and QuarkusTest to let QuarkusUnitTest run first, then QuarkusTest to fix this error.

Yes, you're right. I totally forgot the two things cannot easily coexist 😞.

Messing with the maven-surefire-plugin config and executions is not really what we want because we'd have to replicate it in the quarkus-platform.

Given the above & the requirement in the issue:

Consider only for tests covering interoperability with Quarkus or non-Camel transitives

I think we just simplify this PR to only migrating over the quartz tests. Arguably we could also migrate the the kafka tests. But, service binding is deprecated, thus it's probably not worth it for Kafka.

[JinyuChen97]

No problem, thanks for your feedback, I will reduce the scope of the PR then.