Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan

Thanks Arjan for addressing the elephant in the room. It seems fairly plainly clear that the problem lies in resourcing and staffing levels. Unless this changes soon, I am very wary what the future holds in terms of business viability.

How to exactly solve that I am still trying to figure out, both openly and behind the scenes. Microsoft can only do so much. Ed and I will continue to do what we can until our management tells us otherwise (which based on current customer evidence may indeed happen at some point). We can also ask teams that do something with Jakarta EE APIs (like our messaging products at Microsoft) to invest real engineering time. The problem is that I cannot credibly do that unless I have some concrete evidence major Jakarta EE stakeholders are maintaining a strong engineering commitment to the future of Jakarta EE.

On 11/12/2024 12:39 AM, Arjan Tijms via jakarta.ee-spec wrote:
Hi,

On Wed, 30 Oct 2024 at 18:12, Abraham Marin-Perez via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
We could talk about CDI achieving feature parity with EJB, this will signal users that they can do with CDI everything that they do with EJB, it’s just a matter of how.

I think, at least to me, the how is pretty clear. Reza pretty much filed the exact how some 12 years ago on the old Java EE tracker. Little has changed there. 

The most important matter is actually doing it. 

Looking at myself, my own company, talking to people at conferences, talking to customers etc, the biggest problem is nobody simply has time to do those things. There are always calls, or some customer implementation of something, or some file path issues, or some CI pipeline work that takes precedence. People want to do it, but when you ask them they don't have time yet. You ask them a month later and they still didn't have time. Etc etc. Two years later there's another EE release, and during those two years nobody ever had the time to implement those things.

Kind regards,
Arjan Tijms



 


On Oct 23, 2024, at 10:05 AM, Reza Rahman via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:

Do you mind suggesting alternative verbiage? How about “Provide modernized equivalents of all key EJB functionality using CDI across the platform”?
 
Even if we cannot achieve complete consensus by October 31, I would like to see what level of consensus could indeed be achieved. For example, at a bare minimum, can we commit to a projected delivery date and Java SE support? The release plan (draft?) appears to do so?

From: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Sent: Wednesday, October 23, 2024 6:46 PM
To: Reza Rahman <reza_rahman@xxxxxxxx>
Cc: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
 
I'm not in a position to provide a lot of feedback by October 31.

A quick input is that we should be cautious about language like 'Fully replace EJB with equivalent CDI centric functionality across the platform'. People are going to read that and interpret it as 'we're removing EJB in EE 12' when actually https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=gmail talks about how "we can declare our intent to deprecate EJB". Your more detailed write up is about covering the EJB use cases via other specs so EE 12 users don't have barriers to moving away from EJB.

I understand EJB makes marketing pitches harder, but OTOH a lot of people use it and I don't think scaring them will help Jakarta EE.

On Wed, Oct 23, 2024 at 10:36 AM Reza Rahman <reza_rahman@xxxxxxxx> wrote:
Yes, I understand you folks have been discussing EE 12 to some extent. What I would like to see is if we can achieve more concrete early consensus (including at least some things we can all agree is important to try and deliver) that can be documented (and publicized) as part of the Working Group Program Plan itself.
 
From: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Sent: Wednesday, October 23, 2024 5:15 PM
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; Reza Rahman <reza_rahman@xxxxxxxx>; jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
 
Thank you, Reza, for kickstarting this.

That said, I don't see anything on https://jakartaee.github.io/platform/jakartaee12/JakartaEE12ReleasePlan about November 2024.

On Wed, Oct 23, 2024 at 9:34 AM Reza Rahman via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
Speaking to a friendly JUG leader at Open Community for Java about this, I think I should be even more explicit about deadlines.

The Program Plan is due by the first week of November. To include a specific scope for EE 12 in the Program Plan, a reasonable level of consensus must be achieved by October 31 at the latest. Ideally consensus by October 29 would be great as this is when the next Steering Committee meeting is.
 
From: Reza Rahman <reza_rahman@xxxxxxxx>
Sent: Tuesday, October 22, 2024 11:30 AM
To: jakarta.ee-spec@xxxxxxxxxxx <jakarta.ee-spec@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: Defining Jakarta EE 12 Scope in Program Plan
 
Hi folks,

I would like to see if we can define clear, compelling, and specific
scope for Jakarta EE 12 as part of the Steering Committee Program Plan:
https://docs.google.com/presentation/d/1xUNDHMP_qTHH1wA3m0yCmWVf_sHp41Qd7Opq3FhgINs/edit?usp=sharing.
I believe this is of critical importance at this juncture. If I did not
think so, I would not bother trying. I have detailed all the rationale
here:
https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing.
For those that recall, something very similar was done for Jakarta EE
11, so this isn't exactly without precedent.

I would like to see if this can be done in the following couple of
weeks, when the Program Plan is due.

Thanks,

Reza


Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His

Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His

Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

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

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

Back to the top