-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project generated should depend on microprofile dependencies only and no microprofile-runtimes dependencies #475
Comments
What'd you be your take on that ? @Karm @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/). |
Hello @Emily-Jiang thank you for your answer. Actually quarkus only support MP 3.2 :/ hence |
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.
The text was updated successfully, but these errors were encountered: