There is a very interesting discussion ongoing on the Jakarta EE Community mailing list about forking Eclipse MicroProfile as Jakarta Configuration. While the discussion on the mailing list initially is about the MicroProfile Config specification specifically, it also raises the question of how the strategy of Jakarta EE should be for technical alignment with Eclipse MicroProfile.
Background
A couple of weeks ago, there was a vote in the Eclipse MicroProfile community about how the technical alignment with downstream consumers. Two approaches, the Pull Model and the Push Model were voted on. The Pull Model got the most votes, and thus was selected as the strategy for technical alignment.
In parallel, the discussions regarding the creation of a MicroProfile working group have been going on since October last year. Several suggestions have been explored, including separate working groups, a combined working group with Jakarta EE, or a combination of the two with two working groups linked together with an umbrella working group.
The latest development in this working group discussion is that the Eclipse Foundation has asked the MicroProfile Community to define a charter for a MicroProfile working group independent from Jakarta EE.
Why Fork?
Whether there is a single working group, a group of working groups under an umbrella working group, or just independent working groups is actually not relevant to this discussion. The technical alignment will still be the same. The MicroProfile community has chosen the Pull Model, and this is something Jakarta EE needs to figure out how to relate to.
In my mind, it is pretty simple. Jakarta EE should create a fork of the specifications that makes sense to make a part of the Jakarta EE Platform. There are several reasons for this. I have touched upon a couple of them here.
1. Stability
MicroProfile wants to move fast and break things, while Jakarta EE wants to maintain a certain level of backward compatibility. By creating a fork, Jakarta EE won’t have to address this concern since it will then control the life cycle of its specifications.
2. Cohesion
Java EE, and by succession Jakarta EE, has always been a very cohesive platform. A central piece like configuration will be used throughout the entire platform and it only makes sense that it is in the same namespace as the rest of the platform.
3. Flexibility
By maintaining a fork of the specification, Jakarta EE is free to make modifications that are relevant for Jakarta EE, but maybe wouldn’t be relevant for MicroProfile.
Some Thoughts
As I pointed out in Hashtag Jakarta EE #11, the headache of diverging tines of the fork lands on the vendors that support both Jakarta EE and MicroProfile in the same product. Therefore, it is kind of interesting to see that the vendors that were most in favor of the Pull approach that are all shipping products that are both Jakarta EE and MicroProfile compliant. So, clearly, they must have thought about this and have a solution in place.
Some other reads on the same topic
MicroProfile and Jakarta EE Technical Alignment – Steve Millidge
Proposal on Jakarta EE’s innovation & relationship with MicroProfile – Sebastian Daschner