Project generated should depend on microprofile dependencies only and no microprofile-runtimes dependencies

[soft4rchitecture]

Hello there,
I've recently generated a project using microprofile 3.2 specs and quarkus runtime.

What did I expect

That BOMs and compile-time dependencies be only microprofile ones.
microprofile-runtime dependencies like quarkus have runtime scope.

What happened ?

That BOMs and compile-time dependencies are quarkus only .

Rationale

Actually, the microprofile Specs acts as a Layer between the runtime / implementation and the code we write.
We should code against the microprofile APIs only, and these APIs are then implemented by the microprofile-runtime (quarkus in this case).
That way, since all microprofile-runtime artifacts are runtime-only, referecing them in our codebase would cause a compilation error. We can then safely assume that our application protability is maximised, since we can't code against microprofile-runtimes APIs but microprofile APIs only.
This supports the real use case for microprofile, being able to swap out the micorprofile-runtime with minimal effort.

Obviously, some capabilities are only provided by the microprofile-runtime, and in this case you have to reference microprofile-runtime specific packages and maven dependencies, but that should be a "border" case, one that has to occur, but which limits portability.

[soft4rchitecture]

What'd you be your take on that ? @Karm @Emily-Jiang
I would be ready to volunteer to implement the PR if needed, but I'd love to argue that point.
Thx a lot for your valuable time :)

[soft4rchitecture]

@ketan @atoulme @jponge @sommer any idea ?
thx a lot for your time

[Emily-Jiang]

@soft4rchitecture feel free to propose a PR. I think @Karm added the support for Quarkus. He might have some thoughts on this. By the way, MicroProfile 3.2 is pretty old. You might want to try out the later version of MicroProfile releases (https://microprofile.io/compatible/5-0/).

[soft4rchitecture]

Hello @Emily-Jiang thank you for your answer.
Ok I'll do a PR asap!
As far as the MP version is concerned, my current area of work is about Quarkus 2 these days. Quarkus 2 seems to support MP 3.3 at most... hence using such a version... But i'll try out later versions thx.
Quarkus 3.Final, due for release by feb 2023, will support MP 6.0 ...
But obviously such a pattern of declaring APIs as compile dependencies and should probably encompass all the runtimes and all the versions ....

Actually quarkus only support MP 3.2 :/ hence