Rename webjars-locator to web-dependency-locator

[phillip-kruger]

As discussed, we rename (and relocate) the webjars-locator to something more generic, like web-dependency-locator, as now we support mvnpm and importmaps

[github-actions]

🙈 The PR is closed and the preview is expired.

[gsmet]

Thanks! I added a few comments.

[ia3andy]

This needs to wait, we are discussing using this opportunity to move it to the quarkiverse. https://quarkusio.zulipchat.com/#narrow/stream/191168-core-team/topic/Quarkus.20Web/near/433256889

We are also discussing making it the way (opt-in via extension) to enable serving of mvnpm and webjars which is currently part of vert.x http.

[phillip-kruger]

@gsmet - please check again, I addressed your comments.
@ia3andy - It's not this extension that allows loading from META-INF. This extension only maps the versions path to the non-versioned path, and now also produce a importmap.

We can probably move that logic to this extension. I would assume it's in vertx-http at the moment. That would not change if this extension is in Quarkiverse or here.

My suggestion is we merge here and then see if it will be possible to move that logic out of vertx-http and what the effort and impact would be.

[phillip-kruger]

Things that will break is swagger-ui and graphql-ui.

[ia3andy]

Things that will break is swagger-ui and graphql-ui.

We might be able to keep the compat through builditems if we keep the logic in vertx http, but add the enablement through builditems.

This way the web-dependency extension can use this SPI for all the detected web dependencies and swagger-ui and graphql-ui can only add the required ones.

[gsmet]

Is there a reason why we would want to move it to the Quarkiverse?

It's useful and small and is already there so, except if we have a good reason to move it, I would keep it around.

[phillip-kruger]

I agree @gsmet

[ia3andy]

it was suggested by @cescoffier. I think it belongs more in quarkiverse and while renaming that might be a good opportunity. I have no strong opinion on it.

[cescoffier]

The reason is just to reduce the size of the core and provide independent release cycles.

[phillip-kruger]

@gsmet you make a call. It would be good to get this into 3.10

[gsmet]

It's a bit late for 3.10 unfortunately given we already pushed CR1.

Personally, I would keep this one in core. There are several other extensions I would rather move.

[phillip-kruger]

Can this go into a patch release ? 3.10.1 ?

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 7f695ff.

✅ 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.

⚠️ 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 7f695ff.

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✖	Native Tests - DevTools Integration Tests	Download .m2/repository/io/quarkus	⚠️ Check →	Logs	Raw logs	🚧
✖	Native Tests - Security2	Upload build reports	⚠️ Check →	Logs	Raw logs	🔍

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Tests - JDK 21

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

✖ io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase.sseStream - History

• Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase Expecting size of: [] to be greater than or equal to 2 but was 0 within 10 seconds. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: 
Assertion condition defined as a Lambda expression in io.quarkus.smallrye.reactivemessaging.kafka.deployment.dev.KafkaDevServicesDevModeTestCase 
Expecting size of:
  []
to be greater than or equal to 2 but was 0 within 10 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
	at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)

[gsmet]

Can this go into a patch release ? 3.10.1 ?

No we can't do that. It will have to wait for the next one.