|Re: [jakarta.ee-community] Fork Eclipse MicroProfile Configuration as Jakarta Configuration.|
I don’t like the idea of Jakarta consuming “raw” MP specs for a number of reasons
If I want to support the latest MP and the latest Jakarta EE in the same product then it will be a nightmare, if they run at different pace but are in the same namespace. This will drive us to shipping separate products and therefore Jakarta EE developers will be excluded from the latest innovations in MP.
Jakarta needs to be a consistent platform, it has enough problems with multiple bean models that need unifying. Therefore changes may need to done to specifications to make them consistent with the current state of the overall Jakarta EE platform and to make them work well in the context of Jakarta EE. Given the MP stated goal is to be not concerned with how consumers use the specifications I assume this work will need to be done within the Jakarta efforts.
MP goal is rapid innovation, “move fast, break things” Jakarta’s goal is a stable evolving platform with backwards compatibility requirements. These things are inconsistent. If a developer is using the MP namespace then they know apis may change. If they are using Jakarta apis then they have backwards compatibility guarantees. Mixing the namespace within the Jakarta EE platform breaks that understanding.
Finally for politics. IMHO many members of the MP project do not really see themselves delivering standardised apis in a multi-vendor collaboration, it’s all about innovation and speed. They balk at governance, committees, etc. and wish to move forward like an Apache project. MP should forget about specifications, working groups etc. and leave Jakarta EE to standardize the innovative apis where appropriate into a coherent platform in the Jakarta namespace.
The ideal solution is for Jakarta to see MP as a pool of innovation for ideas which we can adopt, standardise and incorporate in a consistent manner into the overall Jakarta EE platform.
Personally, I don't like the idea of forking, which might sound like a good idea at a first glance. However, once there is a fork, this will give end uers a lot of headache. When they do an import, multiple things pop up and they might end up use partial APIs from either spec. The MP Config and Jakarta Config spec will go out of sync very soon. In short, there should not be 2 config specs.
Having that said, as mentioned by Kevin, MP is focusing on creating WG. Once it is done, there are no IP concerns. Why can't Jakarta EE consume MP Config freely. Also, I suggested a LTS solution for MP Specs to indicate some releases to be consumed by Jakarta etc.
On Thu, Apr 2, 2020 at 7:41 AM Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
Back to the top