quarkus-devservices-deployment does not depend on quarkus-devservices

[vsevel]

Describe the bug

error message Quarkus extension deployment artifact io.quarkus:quarkus-devservices-deployment:jar:3.32.0 does not appear to depend on the corresponding runtime artifact io.quarkus:quarkus-devservices:jar:3.32.0 appears in quarkiverse/quarkus-artemis#1047 and makes the build fail.
this seems to be the case indeed that the dependency is missing. is this an oversight?
cc @holly-cummins

Expected behavior

there should not be any error in goal io.quarkus:quarkus-maven-plugin:3.32.0:go-offline

Actual behavior

the build fails

How to Reproduce?

follow quarkiverse/quarkus-artemis#1047 (comment) : ./mvnw quarkus:go-offline

Output of uname -a or ver

No response

Output of java -version

No response

Quarkus version or git rev

3.32

Build tool (ie. output of mvnw --version or gradlew --version)

maven

Additional information

No response

[quarkus-bot]

/cc @geoand (devservices), @holly-cummins (devservices), @ozangunalp (devservices)

[cescoffier]

🤖 Automatically associated with the WG - Dev Services Lifecycle Working Group based on AI classification.

[holly-cummins]

error message Quarkus extension deployment artifact io.quarkus:quarkus-devservices-deployment:jar:3.32.0 does not appear to depend on the corresponding runtime artifact io.quarkus:quarkus-devservices:jar:3.32.0 appears in quarkiverse/quarkus-artemis#1047 and makes the build fail. this seems to be the case indeed that the dependency is missing. is this an oversight? cc @holly-cummins

Not exactly. There definitely seems to have been an oversight because go-offline isn't working, but the missing dependency is intentional. Historically, we haven't had a runtime module for the devservices. Initially, we didn't think we'd ever need one, and then we did start to need one, but it was too disruptive to add one. So instead we put all the classes that should have been in the runtime devservices module into the runtime core module, which wasn't ideal.

I decided we had to try and fix it, so in #49025, I added the runtime module. As soon as that module exists, our build enforcement expects anything uses the build-time devservices module to have the corresponding dependency on the runtime module in its runtime module. This would be a massive breaking change and require build changes in almost every extension, for no functional gain – and with no backwards compatibility. To avoid that, I put an exception into our build checker which to allow old-model devservice extensions to continue using the deployment module, without requiring them to depend on the runtime module that they don't even need.

New-model devservices should get a friendly error if they're missing the dependency. In the Artemis case, quarkiverse/quarkus-artemis#1047 adds the runtime dependency, so everything should be ok, but it looks like maybe I need to add an extra bypass in the go-offline path. Will investigate.