Make Stork optional for REST Client

[gsmet]

If you want to use Stork, you now have to add the quarkus-smallrye-stork extension, which IMHO makes perfect sense.

This avoids initializing Stork for every application using the REST Client.

I tested several ITs both in JVM and native and it looked fine. Let's hope CI will agree.

Fixes #47337

[github-actions]

🙈 The PR is closed and the preview is expired.

[rsvoboda]

This is great, 👍 for the work.

https://quarkus.io/guides/rest-client doesn't mention Stork at all, so no need to update that one.

I think https://quarkus.io/guides/stork#bootstrapping-the-project and https://quarkus.io/guides/stork-kubernetes#bootstrapping-the-project will need to be updated to include quarkus-smallrye-stork.
https://quarkus.io/guides/stork-reference probably doesn't need any change.

[aureamunoz]

LGTM. But why are the tests on windows failing? Could you please check?

[gsmet]

@rsvoboda let me check the doc. I had a quick look but apparently not a close enough look.

[gsmet]

@rsvoboda I adjusted the doc
@aureamunoz these are just flakes

I will also adjust the quickstarts if this gets accepted.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 70ac695.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 70ac695.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 17

📦 extensions/micrometer-opentelemetry/deployment

✖ io.quarkus.micrometer.opentelemetry.deployment.compatibility.MicrometerTimedInterceptorTest.testTimeMethod_AsyncFailed - History

• Stream has no elements - java.lang.IllegalArgumentException

java.lang.IllegalArgumentException: Stream has no elements
	at io.quarkus.micrometer.opentelemetry.deployment.common.MetricDataFilter.lambda$lastReading$2(MetricDataFilter.java:213)
	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
	at io.quarkus.micrometer.opentelemetry.deployment.common.MetricDataFilter.lastReading(MetricDataFilter.java:213)
	at io.quarkus.micrometer.opentelemetry.deployment.common.MetricDataFilter.lastReadingDataPoint(MetricDataFilter.java:231)
	at io.quarkus.micrometer.opentelemetry.deployment.compatibility.MicrometerTimedInterceptorTest.testTimeMethod_AsyncFailed(MicrometerTimedInterceptorTest.java:150)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at io.quarkus.test.QuarkusUnitTest.runExtensionMethod(QuarkusUnitTest.java:521)

---

⚙️ JVM Tests - JDK 17 Windows

📦 extensions/smallrye-reactive-messaging-amqp/deployment

✖ io.quarkus.smallrye.reactivemessaging.amqp.AnonymousAmqpTest.test - History

• Condition with Lambda expression in io.quarkus.smallrye.reactivemessaging.amqp.AnonymousAmqpTest was not fulfilled within 1 minutes. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in io.quarkus.smallrye.reactivemessaging.amqp.AnonymousAmqpTest was not fulfilled within 1 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1129)
	at io.quarkus.smallrye.reactivemessaging.amqp.AnonymousAmqpTest.test(AnonymousAmqpTest.java:30)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)

[geoand]

Makes sense

[cescoffier]

The code looks good, but we need to make sure the documentation is correct, including the Stork documentation (@aureamunoz, once this is in, we need to change the Quarkus doc on the Stork side).

Note that we are discussing using Stork to handle "addresses" in #46915 - which would make Stork mandatory everywhere.

[gsmet]

@cescoffier I'm a bit unsure it's a good idea to use Stork (and always have Stork initialized) for such a low level feature. It will have an overhead that doesn't seem very necessary.

[rsvoboda]

@gsmet make this one noteworthy?

[rsvoboda]

ok, it has breaking change label, so it will be in release announce

[gsmet]

No changes were necessary in the quickstarts as the Stork modules already depend on quarkus-smallrye-stork.

[rsvoboda]

No changes were necessary in the quickstarts as the Stork modules already depend on quarkus-smallrye-stork.

+1, and Quickstarts Compilation step would detect that

[gsmet]

Actually, it might not if Stork is used transparently. The Quickstarts step is just a compilation step, it doesn't run the tests.

[rsvoboda]

Actually, it might not if Stork is used transparently.

You are right

The Quickstarts step is just a compilation step, it doesn't run the tests.

We can expand to run the tests :) Maybe another ci-* label?