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.
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.