Allow integration with quarkus-vertx-http without a "hard" dependency

[yrodiere]

Description

See #35065 for the original discussion

Quarkus extensions can currently declare an endpoint on the management interface by depending on quarkus-vertx-http-deployment and using a build item specific to vertx-http.

However, some extensions don't have any other reason to depend on vertx-http; they could theoretically be used in a CLI application that has no vertx at all.

For these extensions, adding the dependency to vertx-http is problematic, because there is no way to make the dependency optional:

• They need a dependency to the deployment artifact, and that dependency cannot be made optional
• They also need a dependency to the runtime artifact, and if the dependency to the deployment artifact is non-optional, then the runtime dependency cannot be optional (which makes sense: the deployment's build steps could generate bytecode that depends on the runtime)

Implementation ideas

One solution to get out of this sorry state of affairs would be to introduce a quarkus-vertx-http-deployment-spi artifact, which would:

• depend transitively on quarkus-vertx-http (runtime)
• expose all relevant build items designed to be produced/consumed by other extensions: NonApplicationRootPathBuildItem, RouteBuildItem, ...
• NOT contain any build steps, so its presence in the classpath would not, by itself, affect the build.

Then it would be possible for another extension to depend on quarkus-vertx-http-deployment-spi in its deployment artifact, and to depend optionally (<optional>true</optional>) on quarkus-vertx-http (runtime) in its runtime artifact:

• If an application contains this other extension without quarkus-vertx-http, the contribution to the management interface would get ignored: the relevant build items would not get consumed.
• If an application contains this other extension and quarkus-vertx-http, the contribution to the management interface would be taken into account: quarkus-vertx-http-deployment would be in the build classpath, along with its build steps that consume the relevant build items.

[cescoffier]

One of the issue is that the new (moved) build items depends on Vert.x. So, you will need vert.x (actually vert.x web) as a dependency.

[yrodiere]

Sure, but only at build time, right? If so, that's definitely acceptable.

[cescoffier]

Yes, at build time. We may actually have to depends on the quarkus-vertx-http (runtime) module to get all the API.

[yrodiere]

Ok, works for me. It's fair to require build-time dependencies for build-time features.