我们正在尝试做一个 Microprofile 应用程序。由于 Microprofile 规范仍在蓬勃发展，许多供应商正在涌现。Helidon、OpenLiberty、Kumuliz、WildFly 等等。似乎这些供应商中的每一个都试图通过扩展、内部依赖项和配置模式来创建自己的利基市场（从而形成长期锁定）。
现在，为了避免供应商锁定，我们希望构建仅依赖于标准包的代码并避免任何特定于 impl 的 API 如果我们被迫使用供应商特定的 API，我们并不反对构建适配器或外墙或不同的图案。
这里有一些问题：
我们的想法甚至可能吗？在构建时，我们可以选择通过配置文件包含特定实现的依赖项和配置。
我们选择从 Helidon 和 Quarkus 开始。它们似乎都仅限于 Microprofile 功能，并且不包含像 JMS、EJB 等那样的 JEE fat。我们想对了吗？能有更好的选择吗？
我们是否应该以不同的方式开始/在一个实现上达到我们的应用程序开发阶段，然后对其进行逆向工程以适应第二个供应商？（这确实节省了应用程序的上市时间）。
这里有没有人研究过任何供应商的各个部分的中立性，对于 Microprofile 规范的每个部分？
有人已经走上了这条路吗？
请讨论你的想法..