Remove 'vertx', 'quarkus' from module/image names

[calohmn]

With spring boot variants removed (#3090) the adapter maven module and image names can be shortened. I guess the "vertx" part can be removed as well.
E.g. renaming hono-adapter-amqp-vertx-quarkus to hono-adapter-amqp.

[sophokles73]

If we want to rename the images then I would suggest to indeed also drop the -vertx suffix and use a completely new set of Docker Hub repositories. Otherwise we would start pushing Quarkus based images into the (original) Spring Boot based image repositories, e.g. renaming the hono-adapter-mqtt-vertx-quarkus image to hono-adapter-mqtt-vertx, we would push this image to the Docker repository that we used for the Spring Boot based variant. I would rather not do that as it might be very difficult later on to tell, which image is based on what dev framework/source code.

[sophokles73]

So, the adapter image names then are:

• hono-adapter-amqp
• hono-adapter-amqp-native
• hono-adapter-coap
• hono-adapter-coap-native
• hono-adapter-http
• hono-adapter-http-native
• hono-adapter-lora
• hono-adapter-lora-native
• hono-adapter-mqtt
• hono-adapter-mqtt-native
• hono-adapter-sigfox
• hono-adapter-sigfox-native

while we basically keep the service image names:

• hono-service-auth-quarkus
• hono-service-auth-quarkus-native
• hono-service-command-router-quarkus
• hono-service-command-router-quarkus-native
• hono-service-device-registry-jdbc-quarkus
• hono-service-device-registry-jdbc-quarkus-native
• hono-service-device-registry-mongodb-quarkus
• hono-service-device-registry-mongodb-quarkus-native

Or am I mistaken? @calohmn

[calohmn]

@sophokles73 Why wouldn't we remove the -quarkus part also from the service image names?

[sophokles73]

well, for example the hono-service-auth image name has been used for the vert.xSpring Boot based image so far. I wanted to prevent confusion caused by using the same image name for two different types of images. Starting with 2.0.0 we would use the same name for the Quarkus based images which had been vert.xSpring Boot based before. On the other hand, that is probably only an issue for people trying to use the 2.0.0 chart with older Hono versions. WDYT?

[calohmn]

Yes, I think it's about whether and how we support using the newest (2.0) Hono Helm chart with Hono 1.x images.

I think keeping support for Hono 1.x images would require keeping some 1.x-only logic in the Hono Helm chart, namely support for SpringBoot images and usage of the Jaeger agent sidecar container (instead of the OpenTelemetry Collector sidecar container for Hono 2.0).

On the other hand, users wanting to keep using Hono 1.x images could just stick to the current 1.x Helm chart version, using the honoImagesTag parameter to switch to newer 1.x image versions when new Hono 1.x patch versions get released.

In any case, changing the service image names here as well wouldn't matter much concerning the chart changes, I guess.

If we keep Hono 1.x image support, explicit 1.x related parameters (or 1.x-version parsing of the honoImagesTag) are needed anyway (e.g. concerning the tracing agent). So we could require setting the 1.x image names explicitly then as well (or set them internally according to the 1.x version detection).

[sophokles73]

I think keeping support for Hono 1.x images would require keeping some 1.x-only logic in the Hono Helm chart,

I would rather get rid of all of the deprecated stuff and have a clean 2.0.0 based chart. As you pointed out, users who want to stick to Hono 1.x can still use the 1.x based chart. FMPOV we should strip out everything that is no longer supported in Hono 2.0.0 from the chart as well.

[sophokles73]

I have created an issue with Eclipse Webmasters to create the corresponding repositories on Docker Hub.

[calohmn]

I think the CLI module name and created jar could be renamed as well (from hono-cli-quarkus to hono-cli, as the old CLI).
We can add a note about the different versions on the Hono downloads page.

[sophokles73]

@calohmn anything else to be done here?

[calohmn]

Should we keep the hono-adapters-quarkus and hono-services-quarkus Maven base modules?
I guess they could be integrated with the respective hono-adapters and hono-services modules. WDYT?

[sophokles73]

IMHO we should keep them because they help us to apply the build-docker-image and build-native-image profiles to the service implementation modules only (and not to the base class modules).

[sophokles73]

However, we could remove the -quarkus suffix from the module names ...

[calohmn]

Naming is a bit tricky then, though. We currently have

• hono-adapter-base in directory adapter-base containing adapter base classes
• hono-adapters in directory adapters: container module for the adapter modules
• hono-adapters-quarkus in directory adapters/base-quarkus, containing dependencies and build profiles, used as parent of the actual adapter modules.

Renaming hono-adapters-quarkus to hono-adapters-parent then?