- Don't reinvent wheels by duplicating the effort. Encourage one or the other to consumer specs from the other.
I see allowing Jakarta EE directly consuming technologies from MP has minimal disruption to the end users. Having duplication in both communities does not bring value to the end users but confusion to them. In addition to that, it is a duplication effort to implement both and maintain them for the runtimes.
It seems that the claim of Jakarta EE not allowing depending on MP was somehow accepted without asking why. I saw the argument of MP allowing backward incompatible changes while Jakarta EE does. That was incorrect. Look at CDI 4 for an instance. It introduced many compatible incompatible changes from CDI 3.0.
Another argument of not depending on MP Config, at the moment, there is no configuration solution as yet for Jakarta EE. MP Config is the only solution. It is absolutely viable for the spec to spec the configuration support while the impl can freely choose which configuration they want.
I think we had a long conversation without much agreement made. It might be better to have a call to discuss this further, so basically I am +1 on what David suggested to have a meeting to discuss the technical concerns. Anyone else?
Thanks
Emily