MicroProfile, Jakarta EE, GlassFish/EE4J

[David Blevins]

All,

Moving MicroProfile into the Jakarta EE Working Group and disbanding the MicroProfile Working Group requires a super-majority vote. There are currently four -1 votes and not enough +1 votes to make this happen. Tomitribe, Atlanta JUG and Committer Rep Emerson Castaneda represent 3 of those -1 votes.

We have a proposal we'd like to discuss with the respective communities that would allow the three of us to vote +1, guaranteeing enough votes to move MicroProfile into Jakarta EE.

The Jakarta EE Working Group (WG) charter currently includes GlassFish and other Eclipse implementations within EE4J. The Jakarta EE WG marketing is used to promote and award contributions to GlassFish as contributions to Jakarta EE. The Jakarta EE WG budget is used to fund infrastructure for building GlassFish/EE4J and swag for top GlassFish/EE4J committers. There is currently "Jakarta EE Community Mentor" proposal which will use all Jakarta EE channels to recognize, promote and award contributions to WG projects, including GlassFish/EE4J, excluding other implementations.

While the charter does contain "Provide vendor neutral marketing and other services to the Jakarta EE ecosystem", in practice marketing and budget are provided to GlassFish/EE4J in ways it will not extend to other vendors. The justification is that GlassFish/EE4J are part of the Jakarta EE Working Group and other implementations are not.

Our proposal is to move GlassFish/EE4J into a dedicated Working Group where these activities can happen without compromising the vendor neutrality goal of Jakarta EE. In short:

- Establish an EE4J Working Group and move all implementations out of Jakarta EE
- Move Jakarta EE budget line items associated with implementations (Infra $60k, etc) into EE4J Working Group
- Bootstrap this from the current year Jakarta EE budget as we did to start the MicroProfile Working Group

- Dissolve the MicroProfile Working Group and move all specs to Jakarta EE
- Increase Jakarta EE budget $50k to ensure Eclipse does not lose the $50k MicroProfile Working Group budget
- Revise Jakarta EE charter to remove references to EE4J (PMC representation on Jakarta EE committees would remain intact)
- Add requirement that inclusive vendor-neutral criteria will be established for marketing and other services extended to implementations in the Jakarta EE ecosystem

If there was support for moving GlassFish/EE4J to a separate Working Group, this commitment to neutrality would be applauded and we would vote +1 on moving MicroProfile into Jakarta EE. If all voices come with "why is this so bad" and general pushback, then we do not see value in moving MicroProfile to a Working Group that does not prioritize neutrality.

Would there be support for such a proposal to unite Jakarta EE / MicroProfile in a vendor-neutral Working Group and elevate GlassFish/EE4J into a dedicated Working Group?


-David

[Arjan Tijms]

Hi all,

On Mon, 18 Aug 2025 at 05:36, David Blevins dble...@tomitribe.com wrote:

• Revise Jakarta EE charter to remove references to EE4J (PMC representation on Jakarta EE committees would remain intact)

I agree that any remaining references to EE4J should be removed. Over the past period I’ve worked on separating Jakarta EE–related specifications from EE4J and placing them directly under Jakarta EE. Examples include the Concurrency RI, JSP RI, and EL RI, which were previously coupled with implementation projects. These have since been rebranded (e.g., Concurro, WaSP, and Expressly) to emphasize that they are not more “special” than any other implementation.

The Jakarta EE tutorial has also been moved, though the examples it references still need to follow. The status of the starter project (https://github.com/eclipse-ee4j/starter) may also warrant discussion, as it arguably fits better under Jakarta EE than EE4J.

Maintaining vendor neutrality is important for Jakarta EE, and I fully support that principle.

On a related note, it would be valuable to have a complete set of Jakarta EE 11+ TCK runners for implementations such as WildFly, Liberty, and TomEE as part of the Jakarta EE TCK project. This would allow users to easily execute the TCK—or subsets of it—against any implementation for comparison and additional validation.

The GlassFish team has invested significant effort in making our TCK runners broadly available, enabling straightforward validation and serving as a reference for implementers. While we also encounter challenges, it is not always easy for us to benefit from similar guidance provided by others.

Kind regards,
Arjan Tijms

[Emily Jiang]

Hi David,

Moving GlassFish out of Jakarta EE to maintain fair competition and implementation neutrality is a great idea. GlassFish was the only choice for the rectification implementation in the past due to optional features and specification. Now we have fixed that. There are many other candidates for rectification. We have been trying to move out other specification implementations out of Jakarta EE as Arjan mentioned. I also prefer Jakarta EE focuses on API, Spec and TCKs. Other related projects should be outside Jakarta EE. 

As for setting up a working group, I am with Steve and Kenji so I personally do not think it is necessary as setting up and maintaining a healthy working group is not a small thing. There are many implementation projects under Eclipse Foundation and they work fine. I don't see a reason why GlassFish is different. I assume the current contributors would continue their contributions.

Thanks,

Emily

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/microprofile/D26E33B4-B6D5-40C4-8B1C-C118D5C91E43%40tomitribe.com.

--

Thanks
Emily

[Ondro Mihályi]

Hi David, above all that was already mentioned by others, I want to say on behalf of the whole OmniFish company that we agree with splitting EE4J out from the Jakarta EE Working group. Moving EE4J into a new working group doesn't seem to be necessary, it could become just a top-level project if it already isn't one, and projects inside can evolve as regular Eclipse Foundation projects even without a working group.

Without going into details, I just mention that I believe that GlassFish and other projects in the EE4J space no longer receive marketing endorsement or special resources from Jakarta EE. And if they do, it's certainly not because it's intended but for historical reasons. There's an effort in progress to remove all dependencies between EE4J and Jakarta EE, although some dependencies still exist and it takes time and effort to remove them. In some cases, it's not even possible to completely remove some dependencies, but it's possible to allow other implementations outside of EE4J to be treated in the same way. The Platform TCK needs to be tested against some implementation, and, so far, only the GlassFish project offered help with that. If there are more implementations that offer help and could be used for testing the TCK in the future, it's only a good thing for the whole Jakarta EE ecosystem. On the individual specifications level it's already happening, and some specifications even have the main implementation outside of EE4J, e.g. Jakarta Data has Hibernate, or Jakarta Core Profile has OpenLiberty.and WildFly.

It only makes sense to continue removing the dependencies between EE4J and Jakarta EE WG. If that's a requirement for MicroProfile to agree to moving to Jakarta EE, then MicroProfile needs to wait until all is ready. Though I'm not sure it's worth the delay since Jakarta EE is already moving in the requested direction, based on its own internal motivations. If we delay moving MicroProfile to Jakarta EE for too long, we risk that a lot of work on MicroProfile and Jakarta EE specifications will get stuck in a limbo, waiting until all this is sorted.

All the best,

Ondro Mihalyi

Director, Jakarta EE expert

OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee

Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

_______________________________________________
microprofile-wg mailing list
micropr...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg

[Kito D. Mann]

I'm not invested or knowledgable enough about the nuances here to have a strong opinion, but I will say that limbo is something we want to avoid. I'm afraid this topic is already having that effect...

___

Kito D. Mann | @kit...@mastodon.social | LinkedIn | kitomann.bsky.social
Java Champion | Google Developer Expert Alumni 
Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web Components, Angular, Mobile Web
Virtua, Inc. | virtua.tech
+1 203-998-0403

* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.

--

You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/microprofile/CABd%3DrHe-MRrxEa_r6Fg293K6azz_q%3DxxW2QnSqKA5p3D8Qtodw%40mail.gmail.com.

[Scott Stark]

I fully agree with removing the EE4j implementations as manifest
elements of the Jakarta EE WG, and merging the EE/MP WGs.

I don't see a need for a new working group to deal with this
separation as these are open source projects that can live within the
existing Eclipse Foundation development process.

> --
> You received this message because you are subscribed to the Google Groups "MicroProfile" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/microprofile/D26E33B4-B6D5-40C4-8B1C-C118D5C91E43%40tomitribe.com.

[David Blevins]

Hello communities,

Thank you for the responses. As the discussion has been so far overwhelmingly in favor, I've drafted a potential charter update for continued discussion:

- https://docs.google.com/document/d/1wvxSxoAx80XVMfCr9nqyqj4V9_NC_wVSfQp5fgjsgFI/edit?usp=sharing

All thoughts welcome.


-David

[John Clingan]

I also think that it doesn't need a working group. Seems pretty heavyweight.

[Ondro Mihályi]

Hello, David, Emerson, Atlanta JUG,

I’d like to resume this discussion and try to find a way to address your concerns with moving MicroProfile to Jakarta EE.

I assume that the main concern is with EE4J projects now being part of Jakarta EE and receiving unjust support from the WG budget which other projects don’t get. So I’d like to address this and I have a suggestion.

Previously, I advocated for splitting EE4J and Jakarta EE but I found out that it’s technically almost impossible or difficult at least. It’s now actually the other way around than most people think - Jakarta EE is part of the EE4J top-level project, not vice versa. Splitting would mean that Jakarta EE, not EE4J, needs to move to a new top-level project. But still, if we did that, I believe it’s not even in your own interest and in the interest of MicroProfile, I’ll explain.

In order to successfully promote Jakarta EE and MicroProfile and provide practical solutions to users, it’s better to promote implementations than just standard APIs. Many people don’t understand the concept of specifications and their value over using popular non-standard frameworks directly. And the time when Java EE was meant to build portable apps is long gone. Nowadays it’s easy to port apps from one framework to another, with automation or AI. The value is in the ecosystem, unification, simplicity, and joining the efforts to make more together than apart.

So I suggest that we instead focus on broadening the scope of the Jakarta EE Working Group so that it equally supports any opensource Jakarta EE project, be it in Eclipse or Apache foundation or even vendor-owned repositories. I talked to the Jakarta EE marketing team and they already do it to some extent, promote anything related to Jakarta EE. They just need to know about it. The rest is up to the Jakarta EE WG to officially broaden the marketing scope outside of EE4J and I hope the WG would do that.

I believe it helps everybody if Jakarta EE was an umbrella, not only over specifications or EE4J, but it would support other projects, at least with marketing activities. In the end, it’s funded by fees from WG members, who have projects outside of Eclipse Foundation and it would be fair to support WG members’ opensource projects and also other community projects, in order to make the Jakarta EE and MicroProfile ecosystem more cohesive.

What do you think? Isn’t it better to unify all the community efforts rather than just strictly focus in specifications and leave everything else fith its own battle? Should we pursue this idea in the Jakarta EE WG charter rather than separating from EE4J?

Ondro

On Thu, 28 Aug 2025 at 22:34, David Blevins via jakarta.ee-community <jakarta.ee...@eclipse.org> wrote:

We have oversight of the specification projects and a very detailed specification process that allows us to approve/reject on a case by case basis, so I think we're very well covered to handle edge cases.

We don't have oversight on what gets included in EE4J, so simply reducing our WG scope to projects we've approved as specifications (however we chose to define that) is more than enough.

-David

On Thu, Aug 28, 2025 at 5:41 AM Thomas Watson via jakarta.ee-community <jakarta.ee...@eclipse.org> wrote:

On the topic of the word implementation, we should consider what happens if Jakarta wants to specify some common utilities which would provide an implementation of the specified utility directly in Jakarta.  One such example in OSGi is the tracker specification (https://docs.osgi.org/javadoc/osgi.core/8.0.0/org/osgi/util/tracker/package-summary.html)

This package provides the implementation classes for the trackers as a utility for core framework implementations to use and provide as part of the core runtime of OSGi.  While core framework implementations are free to provide their own implementations instead of taking the one from OSGi, everyone I know just takes the tracker implementation from the OSGi specification.

Does removing the word implementation here prohibit Jakarta from providing utility type classes in the specification?

Tom

---

From: jakarta.ee-community <jakarta.ee-com...@eclipse.org> on behalf of Kenji Kazumura (Fujitsu) via jakarta.ee-community <jakarta.ee...@eclipse.org>
Sent: Wednesday, August 27, 2025 9:24 PM
To: 'Microprofile WG discussions' <micropr...@eclipse.org>; jakarta.ee...@eclipse.org <jakarta.ee...@eclipse.org>
Cc: Kenji Kazumura (Fujitsu) <k...@fujitsu.com>
Subject: [EXTERNAL] Re: [jakarta.ee-community] [microprofile-wg] MicroProfile, Jakarta EE, GlassFish/EE4J

 

David,

Thanks for creating the draft.
Since I do not have the write permission to the documents, the followings are my comments:

==
Eclipse Foundation projects will provide technical implementations of API specifications and TCKs.
==

You remove the words “technical implementations of”, but there is no need to delete the word "implementation."
In fact, several Eclipse projects provide implementations.
If you want to get rid of "implementation," change also the subject to "projects under Jakarta EE Working Group purview" instead of "Eclipse Foundation projects."
But I prefer to maintain as it is, because it is just saying the truth, and it does not affect the working group directions.

==
Define and manage vendor neutral criteria for marketing and other services provided to implementations of Jakarta EE
==

We should be more clarify the scope of “implementations”.
There are some kind of implementations.
- Vendor production implementations
- OSS implementations inside Eclipse Foundation
- OSS implementations outside Eclipse Foundation
I am not sure which types you thought as “implementations”, but I don’t think the Working Group need to promote or provide services to vendors’ products.

-Kenji Kazumura

> -----Original Message-----
> From: microprofile-wg <microprofil...@eclipse.org> On Behalf Of
> David Blevins via microprofile-wg
> Sent: Saturday, August 23, 2025 6:43 AM
> To: jakarta.ee...@eclipse.org; Microprofile WG discussions
> <micropr...@eclipse.org>; microp...@googlegroups.com
> Cc: David Blevins <dble...@tomitribe.com>
> Subject: Re: [microprofile-wg] MicroProfile, Jakarta EE, GlassFish/EE4J
>
> Hello communities,
>
> Thank you for the responses.  As the discussion has been so far
> overwhelmingly in favor, I've drafted a potential charter update for continued
> discussion:
>
>  -

> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1wvxSxoAx80XVMfCr9nqyqj4V9-5FNC-5F&d=DwIGaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=8vjMQ300n2S_eOwZyVXzEgAOp7tnHwSpTvf1R7QmcCc&m=5uxsOwNayCZ8Opp9WhJN_nXp8_GxFX7JOUAE4gzsSXs-4wg2_qR9kI23JjPgA88k&s=9OuZZVZvxb8Ly9qRy62uCK_7PxMwsDVtsK7Tq1-GXMQ&e=
> wVSfQp5fgjsgFI/edit?usp=sharing

> _______________________________________________
> microprofile-wg mailing list
> micropr...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit https://www.eclipse.org/mailman/listinfo/microprofile-wg

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community