Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] MicroProfile, Jakarta EE, GlassFish/EE4J
Hi David B.,

I am David M. from OmniFish, one of three leads of GlassFish, committer of the Platform TCK, Persistence, Faces, contributor to anything so buggy that it tries to break my leg.

On 8/18/25 05:35, David Blevins via jakarta.ee-community wrote:
The Jakarta EE WG marketing is used to promote and award contributions to GlassFish as contributions to Jakarta EE.

Actually this sounds bit weird, even hostile. In fact at least four contributors to GlassFish, including me, are contributing also directly to Jakarta EE projects - my work is usually targeting flaky tests or unreliable scripts and exactly the thing I believe you would like to have - the flexibility to execute the TCK against any implementation possible. In return, all GlassFish has of it is that it uses the TCK CI to validate both Glassfish and the TCK, which is really critical for both sides and saves money as it shortens the path of "issues to be fixed"; despite that, it is temporary and the direction to move GF out of TCK's CI is already set and in progress and again, I believe I am doing most work on it without any funding except my own. 

Some TCK projects already started using different implementations, some even don't use servers. Things are slowly moving - I also personally started integrating TCK executions directly to GlassFish build, just like probably do other implementations, so I can run it on my personal infrastructure (and anybody else can). It works already for Jakarta EE 10, now I am integrating Jakarta EE 11, and just like with 10 I have found problems in the TCK, bugs. 

Fresh example of my contribution to Jakarta EE is here: https://github.com/jakartaee/faces/issues?q=is%3Apr+author%3Admatej

Actually this way I am sponsoring both TCKs and GlassFish, with a positive effect for other implementations and whole ecosystem, because other implementations would face same problems sooner or later. Also note that GlassFish doesn't have funds to have own TCK CI coverage and very probably will never have.

Jakarta EE WG budget is used to fund infrastructure for building GlassFish/EE4J and swag for top GlassFish/EE4J committers.

I have no idea who makes these decisions, but indeed, I received some swags in the past (blanket, mug, sweatshirt, cap). I thought it is from Eclipse Foundation budget and was happy that at least somebody noticed how good work I am doing for Eclipse Foundation for free.

in practice marketing and budget are provided to GlassFish/EE4J

Can I ask for an example of promoting GlassFish on a base of Jakarta EE? Just to get me on your side with this, I would like to agree with that. Sometimes I have opposite feeling. And to be fair, I will mention also Jetty. I did not notice any marketing about it for years despite I know the project is pretty much alive and useful.

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.
I agree to move GlassFish out of the Jakarta EE working group. 

In fact it doesn't change anything - non-GF Jakarta EE contributors just rarely contributed to GlassFish, while part of GlassFish contributors contribute to JEE as much as they can in their free time. Note that we are not a single company, there's one contributing more (OmniFish) and other contributing less (Fujitsu, Payara) and also individuals; all of them are not paid for that, including companies.

Establish an EE4J Working Group and move all implementations out of Jakarta EE

Well, you were talking just about GlassFish until now, but do you mean here also EclipseLink (implementation of Persistence) and other projects? Probably yes, because it would not make sense otherwise. That brings another important question: JEE has huge problems with the lack of contributors. When you take a look on every project under GitHub, there is often just a few contributors, you can count active contributors usually on fingers of one hand. I doubt this step would make it better, on the other side, I don't think it can make it much worse except slowing us all down a bit (every change need some time and work).

Add requirement that inclusive vendor-neutral criteria will be established for marketing and other services extended to implementations in the Jakarta EE ecosystem
Can you elaborate that? Maybe this can bring another problem - current conferences are pretty different than 15 years ago, it is mostly about marketing. Who will do the marketing for Jakarta EE not mentioning any implementation? Or we must enumerate all? Can we do examples? Then we would not be allowed to use any implementation, right? Then as a result, everyone will do presentations about their implementation, but not about Jakarta EE. I know that we had some "grey zone" here, but we had some freedom, so for example when Ondro or Arjan were doing presentations, they usually mentioned other implementations too, not just Piranha and GlassFish. I think Ondro even made some presentation about Quarkus if I remember well.

If there was support for moving GlassFish/EE4J to a separate Working Group
I don't see any reason to have a working group for GlassFish or implementations - what purpose should it have? We have mailing lists and when I asked if we could have regular calls and discuss things, it was refused, because GF committers are all around the world and it is really hard to find a timezone which would not cause pain to some of us. However, we can have a call whenever somebody needs to talk. But I agree that Jakarta EE should continue in the direction of NOT having implementations under the same roof with specifications.
If we could be paid from some budget for our work, ok, then it would make more sense to me.

After all, lets summarize what I think about it (personal view, every GF lead and committer has its own):

- Establish an EE4J Working Group and move all implementations out of Jakarta EE
- Revise Jakarta EE charter to remove references to EE4J (PMC representation on Jakarta EE committees would remain intact)
+1 to moving out, but first prepare all TCK projects for that. Not just documents. If you would contribute this work to TCKs, it would be great.

- 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
- Increase Jakarta EE budget $50k to ensure Eclipse does not lose the $50k MicroProfile Working Group budget

0, as I am working for free on all projects in open source sphere (Jakarta EE, EE4J, MojoHaus, Apache, ...), I don't care about budgets. However ... should I?


      - Dissolve the MicroProfile Working Group and move all specs to Jakarta EE,  

    +1, makes sense to me, I have to answer questions for years about
    this separation.
    

      

        
- Add requirement that inclusive vendor-neutral criteria will be established for marketing and other services extended to implementations in the Jakarta EE ecosystem


      

      -1, I would leave this open for now. Or elaborate how exactly it
      should be established so it does not do any harm.

    
 Thanks,

    
-- 
David Matejcek | OmniFish
david.matejcek@xxxxxxxxxxx

  

























  Back to the top