We are trying to do a Microprofile application. As the Microprofile spec is still blossoming, a number of vendors are emerging. Helidon, OpenLiberty, Kumuliz, WildFly and more. It appears each of these vendors are trying to create their own niche through extensions, internal dependencies and configuration modalities (and hence create a lock in for the longer term).
Now, in order to avoid vendor lock-in, we want to build our code with dependencies only on the standard packages and avoid any impl-specific API If however we are forced to use the vendor specific api, we are not averse to building adapters or facades or a different pattern.
Here are some questions:
Is our idea even possible? At build time, we can choose to include the dependencies and configurations for a specific implementation through the profiles.
We are choosing to begin with Helidon and Quarkus. Both of them seem to be restricted to the Microprofile features only and do not contain the JEE fat like JMS, EJBs et al. Are we thinking right? Can there be a better choice?
Should we start differently/ Reach a stage in our appl development on one implementation and then reverse engineer it to fit the second vendor? (This does save application time-to-market).
has anyone here studied the neutrality of various parts of any vendor, for each part of the Microprofile specs?
Someone has gone down this path already?
Please discuss your ideas..
