Migrate RA Dev Service to the new API

[vsevel]

this is an adaptation to the new dev service api.
I used claude for the initial draft, then reviewed and adapted it.
then I tested it against one of our application in 3 different configurations:

• normal (ie : not compose)
• with a compose file, but letting quarkus launch the container
• with a compose file where I do a compose up prior to launching the test, and using property quarkus.compose.devservices.reuse-project-for-tests=true (and again with value false)

I used https://github.com/quarkusio/quarkus/blob/main/extensions/redis-client/deployment/src/main/java/io/quarkus/redis/deployment/client/DevServicesRedisProcessor.java as an inspiration
here is my compose file:

name: jms-new-dev-service
services:
  artemis:
    image: [quay.io/arkmq-org/activemq-artemis-broker:artemis.2.40.0](http://quay.io/arkmq-org/activemq-artemis-broker:artemis.2.40.0)
    ports:
    - '61616'
    environment:
      AMQ_USER: admin
      AMQ_PASSWORD: admin
      AMQ_EXTRA_ARGS: --no-autotune --mapped --no-fsync

[vsevel]

would be nice to get a review from @holly-cummins

[holly-cummins]

The changes look good to me, although I guess you'll want to see the CI tests (would a re-run fix that cache issue?)

The two comments I have are:

• The serviceConfig method is controlling the restart. Is there anything, outside of the configuration object, for which if it changed, you'd want to restart the dev service? Is there anything in configuration which you'd want to ignore when deciding to do a restart? If so, it's harder because you'd need to make your own data-carrying object, but worth thinking about.
• My intention was that name() would be the feature name, and serviceName would handle the case of things like named datasources. You've got a name variable in the name... but to be honest, it has to go somewhere if you don't want services to be shared across different names, and I don't think there's any functional difference compared to concatenating it with the serviceName.

... but I don't expect you'd want to change anything based on those comments :)

[turing85]

The changes look good to me, although I guess you'll want to see the CI tests (would a re-run fix that cache issue?)

@holly-cummins nope, it did not. The error message suggests that something with quarkus-devservices is broken?

Error:  Failed to execute goal io.quarkus:quarkus-maven-plugin:3.32.0:go-offline (default-cli) on project quarkus-artemis-jms-ra: Execution default-cli of goal io.quarkus:quarkus-maven-plugin:3.32.0:go-offline failed: The following errors were encountered while processing Quarkus application dependencies:
Error:  1) 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

What I do not unterstand is why 3.32.0 and not 3.31.3 pops up here (since @vsevel branched before we upgraded to 3.32.0).

Anyway, running ./mvwn quarkus:go-offline locally results in:

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:3.31.3:go-offline (default-cli) on project quarkus-artemis-jms-ra: Execution default-cli of goal io.quarkus:quarkus-maven-plugin:3.31.3:go-offline failed: The following errors were encountered while processing Quarkus application dependencies:
[ERROR] 1) Quarkus extension deployment artifact io.quarkus:quarkus-devservices-deployment:jar:3.31.3 does not appear to depend on the corresponding runtime artifact io.quarkus:quarkus-devservices:jar:3.31.3
[ERROR]   at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyResolver$ExtensionDependency.collectDeploymentDeps(ApplicationDependencyResolver.java:941)
[ERROR]   ...

I rebased the PR onto the current state of main locally (which bumps quarkus to version 3.32.0), but alas, the same error:

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:3.32.0:go-offline (default-cli) on project quarkus-artemis-jms-ra: Execution default-cli of goal io.quarkus:quarkus-maven-plugin:3.32.0:go-offline failed: The following errors were encountered while processing Quarkus application dependencies:
[ERROR] 1) 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
[ERROR]   at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyResolver$ExtensionDependency.collectDeploymentDeps(ApplicationDependencyResolver.java:1014)
[ERROR]   ...

[turing85]

So funny thing... running ./mvn -DskipTests clean package works just fine, while ./mvnw quarkus:go-offline results in the above error.

@holly-cummins could it be that something is broken in quarkus-devservices with respect to quarkus' go-offline target?

[github-actions]

🚦Reports for run #2575🚦

Reports will be posted here as they get available.

😔 JUnit JVM Test failed

Passed	Failed	Skipped
✅ 0	❌ 0	⚠️ 0

You can see the report here.

😔 JUnit Native Test failed

Passed	Failed	Skipped
✅ 0	❌ 0	⚠️ 0

You can see the report here.

[vsevel]

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

that is actually correct: https://github.com/quarkusio/quarkus/blob/3.32/extensions/devservices/deployment/pom.xml does not depend on quarkus-devservices

is this expected @holly-cummins ?

[vsevel]

I created quarkusio/quarkus#52695