I and the OmniFish team welcome this proposal very much. In terms of naming, I think we can have a good discussion as all the involved parties are interested in a good solution.
We see the there's a high potential to make it a win-win-win decision, for MicroProfile, Jakarta EE, and users of both platforms:
MicroProfile would benefit from a reduced overhead and just rely on Jakarta EE processes. it could also benefit from Jakarta EE marketing activities and become a part of the bigger Jakarta EE family, with a bigger marketing budget, paid developer evangelist, etc. I also believe that Jakarta EE Working Group can create some autonomy for MicroProfile and relax some processes for it if desired, e.g. have a separate steering committee or a sub-committee, with public meetings. Or Jakarta EE steering committee itself could become more transparent and open their meetings to the public
Jakarta Working Group would benefit with better alignment and joining marketing efforts. It's easier to market a single brand with a sub-brand, rather than market 2 different brands and still pretend they are sort of the same thing. Personally I think that Jakarta EE would benefit more if MicroProfile specs that aim to become part of Jakarta EE, like Config in Core Profile, would change the package prefix to jakarta, together with a review approval from the Jakarta Specification commitee. Without that, it's not likely that Jakarta EE could depend on MP specs, and the benefit for the Jakarta EE platform from joining the 2 working groups would be only in the marketing area
Users would benefit from a unified approach to the whole Jakarta EE + MicroProfile API. They would see a unified marketing, they could trust the platform as a whole, they would not be confused anymore by 2 different things. Think of it as a step forward. Even in the Spring community, there's Spring framework and SpringBoot framework. But most people only talk about SpringBoot nowadays. Just because people want to talk simple. They all know Spring and SpringBoot are 2 different things but they don't want to complicate things. In the same way, if people can just talk about Jakarta EE on the highest level, and then go into details with MicroProfile, Web Profile, Core Profile, etc., it makes their life easier.
Therefore I suggest to refine the proposal, and consider:
Accept that package prefix changes to jakarta for specs that aim to become part of the Jakarta EE platform or its profile. Or change the prefix for all specs at once to align them with the other Jakarta specs
Request that Jakarta EE either modifies its process to better adhere to MicroProfile values (openness, simplified governance, relaxed rules for breaking changes for specs outside of the Jakarta EE platform, if needed)
I believe that, with these changes, the proposal would be neneficial to all the related parties - both working groups and the community of users and vendors
Ultimately branding is everything to be honest in
terms of technology success in the market. I don’t think there is
a good enough reason to dilute brands more than is really
necessary.
I certainly understand people
wanting to hold onto javax. I did too. Honestly though, the
impact was pretty manageable. Most customers we see don’t seem
to struggle with it much. Given the far more limited use of
MicroProfile, I genuinely believe the impact will be minimal
or perhaps even negligible. The benefit is having a strong and
uniform umbrella brand going forward while retaining some
separation for MicroProfile via jakarta.microprofile.*.
Since we
don't need to change namespace, why should we cause headaches to
the MicroProfile customers?
This is a great direction and
it is an easy +1 from Microsoft.
In terms of naming, things like Jakarta Health is a lot less
of a mouthful than Jakarta MicroProfile Health. We do
believe maintaining the MicroProfile brand and
differentiation is important and valuable. For example, the
resulting new Jakarta Profile could be called "Micro
Profile". Similarly, associated sensible package names that
would be clear to the community and customers could be:
jakarta.microprofile.*. Unfortunately things like
org.microprofile.* inside Jakarta EE may prove to be too
confusing as it implies a separate domain.
Using any other namespace
instead of org.eclipse.microprofile.* would cause unnecessary
migration effort. People might still remember how hard the
Eclipse Foundation tried to keep the javax namespace to avoid
the migration effort. Right now, we have the pleasure to keep
the microprofile namespace. Why should we throw away the
luxury and force the MicroProfile customers to go through
migration? As for the spec name, it is less important as it
has not much application impact.
Thanks
Emily
From a Microsoft standpoint, we will do whatever we sensibly
can to ensure this is not seen as a zero sum outcome dynamic
for anyone and only a net gain for all.
On 3/19/2025 4:37 PM, John
Clingan via microprofile-wg wrote:
At
yesterday's MicroProfile Steering Committee call, John
and Emily presented "Proposal: Host MicroProfile in
Jakarta EE".
Before replying to this post, please review the
meeting minutes to
see what has been discussed. Please use this thread to
continue the discussion. The proposal is at a high
level, and some details would need to be worked out if
this proposal moves forward.
However,
for the proposal to move forward, we would need to have
a vote. We are not there yet because the details
matter.
Let's
discuss the details in this thread, which is dual-posted
to the Google Group and the MicroProfile Working Group
email alias.
For
those that attended the meeting, please review the
minutes for accuracy.
