JUnit support - disable observers declared on mocked beans

[mkouba]

• resolves InjectMock does not work on observer method #11079

[geoand]

Really nice!

[famod]

Awesome! Will take me some time to review/test this, so don't wait for me in case the others approve before me.

/cc @mickroll in case you want to try this out: clone this branch & run mvn -Dquickly & use 999-SNAPSHOT in our project

[mkouba]

/cc @mickroll in case you want to try this out: clone this branch & run mvn -Dquickly & use 999-SNAPSHOT in our project

I'd recommend to build quarkus with mvn clean install -T 1C -DskipTests -DskipITs -Dquickly...

BTW there was a typo in the observer generator I've just fixed and force-pushed...

[famod]

I'd recommend to build quarkus with mvn clean install -T 1C -DskipTests -DskipITs -Dquickly...

Parallel build is flaky, especially for first time builds (see #10859) and quickly should also skip all tests, but yeah eveyone has his/her way. 😉

[mkouba]

Yep, this time we don't want to run the tests but build the quarkus as quick as possible ;-).

[mkouba]

The windows job got cancelled in 3h 1m 9s... Is it expected to take so long?

[geoand]

Nope, it should finish in 2 (or close to that)

[mkouba]

Ok, so this time JDK Java 14 JVM Gradle Tests:

2020-08-03T15:11:24.3416664Z GrpcDevModeTest > main() FAILED
2020-08-03T15:11:24.3417128Z     org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference, java.util.concurrent.atomic.AtomicReferencejava.lang.String, java.lang.Stringboolean was not fulfilled within 1 minutes.
2020-08-03T15:11:24.3417586Z         at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
2020-08-03T15:11:24.3418042Z         at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
2020-08-03T15:11:24.3418422Z         at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
2020-08-03T15:11:24.3418817Z         at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
2020-08-03T15:11:24.3419195Z         at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:864)
2020-08-03T15:11:24.3419581Z         at io.quarkus.test.devmode.util.DevModeTestUtils.getHttpResponse(DevModeTestUtils.java:126)
2020-08-03T15:11:24.3419979Z         at io.quarkus.test.devmode.util.DevModeTestUtils.getHttpResponse(DevModeTestUtils.java:115)
2020-08-03T15:11:24.3420407Z         at io.quarkus.gradle.devmode.QuarkusDevGradleTestBase.getHttpResponse(QuarkusDevGradleTestBase.java:108)
2020-08-03T15:11:24.3421080Z         at io.quarkus.gradle.devmode.GrpcDevModeTest.testDevMode(GrpcDevModeTest.java:15)

I don't think it's related. Can anyone confirm my assumption?

[geoand]

Yes, that is totally unrelated.

@michalszynkiewicz seems like io.quarkus.gradle.devmode.GrpcDevModeTest is flaky.

[michalszynkiewicz]

@geoand thanks for letting me know. The weird thing is that it failed before any modifications have been made...
Is it possible that gradle is not able to start dev mode in a minute?

[michalszynkiewicz]

also, have you seen this failure on any other PR?

[geoand]

I have seen gradle failures from time to time, but TBH I don't remember which class was causing them

[gsmet]

@michalszynkiewicz I confirm I have seen it in other pull requests.

[michalszynkiewicz]

@gsmet always for grpc?

[michalszynkiewicz]

@glefloch do you have some suspicions what may be the cause?

[mkouba]

@gsmet Are we safe to merge this PR?

Pls move the gradle CI discussion to a separate issue.

[manovotn]

Apologies for late review (PTO).
PR looks good.

[gsmet]

Yeah, failure looks unrelated.

Should this be backported to 1.7.0.Final or it's not worth it?

[glefloch]

Gradle tests are slow but I don't think they are as slow as taking a minute to start the devmode. There used to be issues on windows with some locks inside Gradle cache but not on Unix.