Re: [jakarta.ee-community] [jakartaee-platform-dev] DISCUSS: resolve mat

[Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>]

Sorry for the cross-posting and intertwined threads. Here is my reply on the other list, or maybe on this one (I lost count)...

I would like to point out, as Ed Bratt did in the Steering Committee yesterday when this topic came up, that the API jar is NOT a normative artifact. It is a bi-product when the Javadoc and signature tests are generated, and distributed to Maven Central for convenience. Taking that into consideration, there is no need for any actions at this point. 

It may be a good idea going forward that the Platform Project replaces the profile dependencies with explicit listings of the individual specifications. This will avoid confusion and be better aligned with the wording of the specification.

Ivar

On Wed, Mar 26, 2025 at 11:31 AM Reza Rahman via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:

This is where you will need a real process expert. Maybe Ivar? My old JCP understanding is that the Maven stuff is not actually strictly part of the spec (after all, we hope to outlive Maven/ANT/Gradle/whatever). You can finalize the spec and figure it out, as long as it is within a reasonable time and everyone knows what's going on. You could also potentially change it long after the spec release is done as long as it is not too crazy of a change from a strictly spec perspective (and I bet most people won't even notice a quiet switch since this is a new thing anyway).

The old mess of how the platform spec and profiles in Maven was done is a story for another day. One needless mess evasion maneuver at a time...

On 3/26/2025 6:11 AM, Ed Burns via jakartaee-platform-dev wrote:

Thanks Reza for being a true guardian of Jakarta EE.

Considering the Web Profile ballot is currently underway and we are actively pushing for it to successfully close as soon as possible with an APPROVED result, we must urgently determine the impact of this matter (CoreProfileWebProfile for discussion) on the ballot. 

Let me restate my understanding of the plan of record for the Platform Profile (incorrectly referred to as the "Full" profile) and the Web Profile for EE 11.

1. [Happening right now] Deliver all necessary artifacts to start and approve the ballot for EE 11 Web Profile.
1. Spec -- Web Profile ballot satisfaction version
2. API jar -- Web Profile ballot satisfaction version
3. Platform Profile TCK -- Web Profile ballot satisfaction version
4. Ratifying compatible implementations
1. GlassFish 8 on 17
2. GlassFish 8 on 21
2. [Happening after APPROVED for 1.] Continue to resolve matters for the Platform Profile TCK -- Platform Profile ballot satisfaction version.
3. [Happening after 2.] Create all necessary artifacts to start and approve the ballot for EE 11 Platform Profile.
1. Spec -- Platform Profile ballot satisfaction version
2. API jar -- Platform Profile ballot satisfaction version
3. Platform Profile TCK -- Platform Profile ballot satisfaction version
4. Ratifying compatible implementations
1. GlassFish 8 on 17
2. GlassFish 8 on 21

Here is the current state of artifact 1.b:

--- dependency:3.6.0:tree (default-cli) @ jakarta.jakartaee-web-api ---

[INFO] jakarta.platform:jakarta.jakartaee-web-api:jar:11.0.0-SNAPSHOT

[INFO] +- jakarta.platform:jakarta.jakartaee-core-api:jar:11.0.0-SNAPSHOT:compile

[INFO] |  +- jakarta.ws.rs:jakarta.ws.rs-api:jar:4.0.0:compile

[INFO] |  +- jakarta.json:jakarta.json-api:jar:2.1.3:compile

[INFO] |  +- jakarta.json.bind:jakarta.json.bind-api:jar:3.0.1:compile

[INFO] |  +- jakarta.annotation:jakarta.annotation-api:jar:3.0.0:compile

[INFO] |  +- jakarta.interceptor:jakarta.interceptor-api:jar:2.2.0:compile

[INFO] |  +- jakarta.enterprise:jakarta.enterprise.cdi-api:jar:4.1.0:compile

[INFO] |  +- jakarta.inject:jakarta.inject-api:jar:2.0.1:compile

[INFO] |  \- jakarta.enterprise:jakarta.enterprise.lang-model:jar:4.1.0:compile

[INFO] +- jakarta.servlet:jakarta.servlet-api:jar:6.1.0:compile

[INFO] +- jakarta.servlet.jsp:jakarta.servlet.jsp-api:jar:4.0.0:compile

[INFO] +- jakarta.data:jakarta.data-api:jar:1.0.1:compile

[INFO] +- jakarta.enterprise:jakarta.enterprise.cdi-el-api:jar:4.1.0:compile

[INFO] +- jakarta.el:jakarta.el-api:jar:6.0.1:compile

[INFO] +- jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api:jar:3.0.2:compile

[INFO] +- jakarta.faces:jakarta.faces-api:jar:4.1.2:compile

[INFO] +- jakarta.websocket:jakarta.websocket-api:jar:2.2.0:compile

[INFO] +- jakarta.websocket:jakarta.websocket-client-api:jar:2.2.0:compile

[INFO] +- jakarta.ejb:jakarta.ejb-api:jar:4.0.1:compile

[INFO] +- jakarta.transaction:jakarta.transaction-api:jar:2.0.1:compile

[INFO] +- jakarta.persistence:jakarta.persistence-api:jar:3.2.0:compile

[INFO] +- jakarta.validation:jakarta.validation-api:jar:3.1.1:compile

[INFO] +- jakarta.authentication:jakarta.authentication-api:jar:3.1.0:compile

[INFO] +- jakarta.security.enterprise:jakarta.security.enterprise-api:jar:4.0.0:compile

[INFO] +- jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api:jar:3.1.1:compile

[INFO] \- org.glassfish:jakarta.faces:jar:4.1.2:provided

[INFO] ------------------------------------------------------------------------

QUESTION: is it possible for us to defer concrete action on CoreProfileWebProfile until we reach step 2 above? Here is one reason where I hope we can defer concrete action until we reach step 2:

• The set of artifacts we are producing for 1. is disjoint from the set of artifacts we are producing for 3.​

I create this discussion thread for the purpose of answering the above question.

Thanks,

Ed

Jakarta EE release co-coordinator.

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of lenny--- via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Date: Wednesday, March 26, 2025 at 05:28
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: lenny@xxxxxxxxxxxxx <lenny@xxxxxxxxxxxxx>, Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>, Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Sanity Check - Making Core Profile a Dependency of Web Profile

Totally agree, Reza, thank you for the link as well.

Just FYI, Manfred, you are right about Full / Web Profile dependency, only it was before Jakarta EE 10.

Prior to EE 10, there were no dependencies between profiles, however, since 10, Full profile depends on Web profile.

However, that “older” model had it’s own big challenges, being inflexible and rigid, but I digress :)

On Mar 25, 2025, at 11:22 PM, Reza Rahman via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

All of this is properly solved once “Micro Profile” moves to the platform where it rightfully belongs. No weird band aids necessary to try to solve a compound fracture.

 

---

From: Manfred Riem <m_riem@xxxxxxxxxxx>
Sent: Wednesday, March 26, 2025 12:14 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Reza Rahman <reza_rahman@xxxxxxxx>; Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: RE: [jakartaee-platform-dev] Sanity Check - Making Core Profile a Dependency of Web Profile

 

Hi,

Reza, thank you for the link.

It is easy to forget to keep these guidelines front and center.

I think the whole integration of all these things whether it is Core Profile, Web Profile, MicroProfile, CDI Lite, Servlet, Jakarta REST, JCA, or JCA or the entire Platform, it is a lot trickier than people realize. Why did we have Managed Beans and CDI, why do we have similar annotations here and there, why can't you just use MicroProfile in a Web Profile runtime without gotchas or any of the MicroProfile specifications separately? Well, integration is hard. And I know as I am still on what has proven to be an extremely long road with the Piranha project to certify against the Core Profile let alone the Web Profile or even the full platform.

It is from that perspective I would implore folks to take a step back and look at the larger picture here. In the end a developer does not care about this profile, that platform, that specification or whatever.

What they care about is being able to use it without hassle and gotchas and if anything puts that at risk we should think twice about it.

In closing I want to call out that historically we shipped separate API jars and documentation for the platform and Web Profile and there was no Maven dependency between the two. So, from that perspective I fail to see why Core Profile should be any different.

Manfred Riem
"Have you prompted your prompt today?"

-----Original Message-----
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Reza Rahman via jakartaee-platform-dev
Sent: Tuesday, March 25, 2025 10:34 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Reza Rahman <reza_rahman@xxxxxxxx>; Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Sanity Check - Making Core Profile a Dependency of Web Profile

This brief follow-up is not aimed at anyone in particular but rather a general attempt to try to potentially better inform anyone interested in this discussion. It is helpful to carefully read the Profiles section in the Jakarta EE specification:
https://jakarta.ee/specifications/platform/11/jakarta-platform-spec-11.0-m5#a3212.
The reason I am familiar with this content is because I helped formulate this as part of the Java EE 6 expert group so many years ago. I understand this all seems pedantic to some, but this is the nature of open specifications as opposed to just open source. The accuracy, reliability, and integrity of what is in these documents matters.

On 3/25/2025 7:38 PM, Reza Rahman wrote:
> Hello folks,
>
> Today in the Jakarta EE Steering Committee meeting, I came to learn
> that a Core Profile dependency was added to the Web Profile Maven POM.
> I am unconvinced this was done through adequate deliberation and
> consensus (that is, votes to support a truly majority stakeholder
> decision). More than anything else, I want to ensure that in fact has
> happened or happens soon.
>
> Adding a Core Profile Maven dependency for Web Profile is problematic
> for the following reasons:
>
> * Strictly from a specification perspective (please read the actual
> specification to verify this), Core and Web are separate profiles
> targeted to separate domains. The Web Profile is geared to web
> applications while the Core Profile is geared towards microservices.
> Neither profile refer to each other and can freely evolve to meet the
> needs of their respective target use cases.
>
> * While from a specification perspective no such dependency actually
> exists, the Maven POM will give end users the impression that there is
> such a concrete dependency. Moreover, users will effectively have this
> dependency chain in their applications and may even come to rely on it.
>
> * If the Core and Web Profiles do evolve separately (for example by
> adding or removing APIs), this dependency chain will get in the way,
> will no longer work, or will require awkward Maven gymnastics to make
> work. All it would take is needing separate out-of-sync releases of
> these profiles for things to break.
>
> * It risks reinforcing an impression that passing the Web Profile TCK
> means also passing the Core Profile TCK. This is not the case and you
> need to in fact go through separate certifications for each profile.
>
> I think the best solution is to not introduce this dependency at all,
> get back to properly separated Core and Web profiles just as the
> actual specification reflects, and proceed with the Web Profile
> release. If this must be done and there is proper consensus, it should
> be done by updating the Web Profile specification to explicitly
> reference the Core Profile specification. The Core Profile
> specification should be updated to evidently serve as a "base" Jakarta
> EE profile in addition to serving it's currently identified domain.
>
> I understand everybody is working hard to get releases out and
> everyone has the best of intentions. However, I feel these things need
> to be carried out with the weight that Jakarta EE has in the Java
> ecosystem. I want to make sure that's actually the case. I hope that
> is understandable.
>
> Thanks,
>
> Reza
>
> P.S: I have already discussed this matter with Ed before commencing
> this communication in case you are wondering.
>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

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

--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.