Re: [microprofile] Jakarta EE x or higher

[John Clingan]

During the Live Hangout I started the aligning with requiring an MP update to support a newer Jakarta EE version. As the conversation continued, my thoughts started to shift towards not making the requirement. After thinking about it more (which I indicated I would do), I like the idea of not requiring a MicroProfile update to support a newer Jakarta EE version.

* It gives implementations more flexibility for how to support MicroProfile. This enables more “compatible implementations” per MicroProfile release. This is good for MicroProfile.

* It gives customers more flexibility

* Once we address some of the issues Ed brought up regarding the TCK and binary artifacts, it should be less work for MicroProfile to support newer Jakarta EE versions 

* To Roberto’s point, we are revisiting an already-made (recent) decision. Thanks for posting the thread link.

On Jan 30, 2023, at 8:53 AM, 'Roberto Cortez' via MicroProfile <microp...@googlegroups.com> wrote:

Hi,

As David stated, we discussed this in the past and concluded in the following vote:

https://groups.google.com/g/microprofile/c/25r51gGugXg

I’m fine to revisit past discussions or decisions. Still, I have to question if it is right to review a discussion that should have been settled (with a unanimous decision after many other talks) in only half a year.

"A MicroProfile specification should not change versions just for a new Jakarta EE version unless the MicroProfile specification must change to support the new Jakarta EE version. It is possible for a MicroProfile specification version to work on multiple versions of Jakarta EE."

On the last call, we discussed when MP should update. My feeling was that people in the call generally agreed that MP was not required to update if the new Jakarta version was compatible with the current MP version. So, can we agree that the first sentence of the stamente is accurate? "A MicroProfile specification should not change versions just for a new Jakarta EE version unless the MicroProfile specification must change to support the new Jakarta EE version”

I guess the second part may raise some other questions. It does not define a minimum version, leaving the combinations between Jakarta and MicroProfile open to interpretation. I think it is reasonable to define a minimum version (as we already do with the Java version).

Currently, MP 6 is based on Jakarta 10. If Jakarta 11 comes up and it is compatible with MP 6.0, I think that would be great. We could market from day one that MP works in both 10 and 11. Implementations can certify with both combinations, and passing the TCK for both should be enough proof for compatibility. If Jakarta 11 breaks the compatibility, it is okay. We release a new MP version, and Jakarta 11 becomes the new minimum version. I don’t see a reason for us to release an empty version just for “alignment”. This is not how most projects operate. If we indeed want to keep such alignment, then I agree that, technically, there is no value in keeping them separate.

Cheers,

Roberto

On 30 Jan 2023, at 12:36, Arjan Tijms <arjan...@gmail.com> wrote:

Hi,

On Monday, January 30, 2023 at 12:43:59 PM UTC+1 Emily Jiang wrote:

MicroProfile runtime x implements all of the 8 core MicroProfile Specs in MP release y but not the baseline Jakarta EE. How can this runtime be listed as a MicroProfile implemenation?

Implement the baseline Jakarta EE?

 

Isn’t this the same as:

“MicroProfile runtime x implements 6 of the 8 core MicroProfile Specs in MP release y but not the remaining two MicroProfile Specs. How can this runtime be listed as a MicroProfile implemenation?”

And the answer would be similar:

Implement the remaining 2 specs, right?

Kind regards,

Arjan Tijms

 

Dátum: štvrtok 26. januára 2023, čas: 23:14:49 UTC+1, odosielateľ: Reza Rahman

Just double checked to see if dependencies marked ‘provided’ are transitive. They are not. Hence going that route will also pose a potential usability hazard.

Please disregard my prior comment about marking the Jakarta EE Core dependency ‘provided’ as a fair point. I think the way things are with MicroProfile is really the most pragmatic choice.

From: Reza Rahman <m.reza...@gmail.com>
Sent: Thursday, January 26, 2023 11:05 AM

To: microp...@googlegroups.com <microp...@googlegroups.com>
Subject: Re: [microprofile] Jakarta EE x or higher

 

I think the MicroProfile Lite route is something we should get plenty of end user feedback on before we consider seriously. I cannot think of an example where something is shipped with a missing compile time dependency. Aside from all the other ambiguities that this option comes with, it may be a potential usability hazard.

From: 'Emily Jiang' via MicroProfile <microp...@googlegroups.com>
Sent: Thursday, January 26, 2023 9:57:55 AM
To: microp...@googlegroups.com <microp...@googlegroups.com>
Subject: Re: [microprofile] Jakarta EE x or higher

 

On Thu, Jan 26, 2023 at 2:08 PM Reza Rahman <m.reza...@gmail.com> wrote:

Just want to understand - doesn’t MicroProfile have compile dependencies on Jakarta EE APIs in addition to runtime dependencies?

MicroProfile 6.0 and prior have compile dependency on Jakarta EE APIs. In this case, end users don't need to specify the dependency on Jakarta EE APIs (the ones included by MP).

 

So an application that just specifies MicroProfile Lite as a dependency wouldn’t even compile without also explicitly adding Jakarta EE as a dependency, correct?

Correct. For MP Lite, they will need to explicitly add Jakarta EE dependency. In this way, they can choose which version to pull in based on the runtime they use.

Thanks

Emily

 

From: 'Emily Jiang' via MicroProfile <microp...@googlegroups.com>
Sent: Thursday, January 26, 2023 7:07:08 AM
To: MicroProfile <microp...@googlegroups.com>
Subject: Re: [microprofile] Jakarta EE x or higher

 

In addressing David's request regarding the certification, I propose the following to make it clear:

1. In MP 7.0, we introduce one additional release- MP 7.0 lite: 8 MP specs only without any Jakarta EE specs while the umbrella release will continue packing Jakarta EE Core Profile plus MP 7.0 lite - we call it MP 7.0 full.

In this case, the only requirement for MP 7.0 lite is to pass the 8 MP TCKs and this allows runtime to pull in any Jakarta EE impls.

MP 7.0 full - continue the pattern of previous MP releases. The certification requires passing 8 MP TCKs plus Jakarta EE 10 Core Profile.

If we want to move up to the Jakarta EE 12 core profile, we need to release another different version of MP (could be MP 7.x or MP 8). Basically agreed with Reza on the comments (Jan 24, 2023).

As for other comments on the transitive dependencies, it should be the case for MP 7.0 lite as end users have to specify the Jakarta EE dependencies clearly. For MP 7.0 full, there is no need as the Jakarta EE 10 Core Profile will be included (a lot of end users like this option).

On Thursday, January 26, 2023 at 1:34:48 AM UTC Reza Rahman wrote:

Personally I think it's become pretty normal practice to have transitive dependencies. Spring has done it for ages. It would be expected that MicroProfile express Jakarta EE Core as a dependency. I think that's really the practical relationship.

That seems to be exactly what MicroProfile 6 is doing: https://repo1.maven.org/maven2/org/eclipse/microprofile/microprofile/6.0/microprofile-6.0.pom.

Note, transitive dependencies can be easily overridden if needed.

That being said, I think it's a fair point the transitive dependency should be 'provided' instead of 'compiled'. I don't think most end users would even notice the difference in practice. Note sure why this isn't the case in MicroProfile 6.

If you specify transitive dependency, you have to add the Jakarta EE 10 Core Profile as an dependency, which is an extra step. Since MP 6.0 clearly specifies the inclusion of Jakarta EE 10 Core Profile, it does not make sense to specify as an transitive dependency. By the way, this is the pattern estabilished since MP 1.0, which was to package 3 Java EE 7 specs (CDI, JSON-P, JAX-RS).

I will create a google doc to capture the options for a further discussion next week.

Hope this helps!

 Thanks

Emily

On 1/25/2023 4:56 PM, Ed Bratt wrote:

Perhaps this is a counter proposal, perhaps not ...

MicroProfile (it seems) differs from Jakarta EE in that there are binary artifacts that are (or appear to be) normative. Given this, I would propose

• Normative artifacts, whatever they are, should all be clearly and accurately described in the specification documentation. They should be described with sufficient detail so there is no question about the requirements imposed on implementations.
  
• To the extent possible, the TCKs should verify that the required artifacts are used in the implementation, in addition to whatever other assertions the specification team has determined as required (In the event that is a requirement cannot be verified in the TCK this should be prominently written in the documentation).
  
• TCK certification result documentation requirements should also be clearly stated (specifically, if we require Core Profile certification results -- I don't think we did in MicroProfile 5, for example but I notice the one CCR for v6 does include Core Profile results.).

I would recommend that Jakarta EE Core Profile, since it is not produced by MicroProfile., not be included in the list of 'normative' artifacts produced by the MicroProfile specification. In a Maven POM, for example, it should be listed as a 'provided' dependency and this dependency should not be overly restrictive. (I don't think we want to keep track micro-releases produced by another working group, for example.)

On Tuesday, January 24, 2023 at 7:42:30 PM UTC-8 dble...@tomitribe.com wrote:

Thanks for responding, Reza.   All, definitely do follow Reza’s example and chime in with your thoughts when you have time.

-David

 

--
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 on the web visit https://groups.google.com/d/msgid/microprofile/3375cdaf-77df-4fa8-ab31-d8bbadcbfb37n%40googlegroups.com.

--
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 on the web visit https://groups.google.com/d/msgid/microprofile/81B42EDE-0439-4D10-A4F4-03F2DE2FE2CD%40yahoo.com.

[Ondro Mihályi]

I actually agree with what Roberto wrote.

But I was reacting on something a bit different to what was decided in the past. The vote in the past was about the situation when MP requires a lower version of Jakarta EE and is used in combination with a newer version of Jakarta EE. As long as the newer version of Jakarta EE doesn't break anything in the common specs (i.e. in Jakarta EE Core Profile), it makes sense that MP can be combined with both the newer and older EE version. Both Jakarta EE 9 and 10 introduced incompatible changes (jakarta namespace in 9, CDI default bean discover in 10), so that situation has never happened. But I hope that EE 11 doesn't introduce any breaking change and then MP 6 could be used with both EE 10 and 11.

But I believe that the question discussed in this thread is - if MP requires a newer version of EE, what to do with implementations that implement all new MP specs but don't implement the new version of the EE Core Profile, only an older version? Emily proposed to solve this with a MicroProfile Lite profile but I think this is a virtual problem and there are already simple solutions:

1. In case that the next version of Jakarta EE is compatible with the old one and MP doesn't require any new Jakarta EE features, MP can maintain the older Jakarta EE version as requirement and allow a new version. I believe this is what Roberto and John suggested here.
2. If there are breaking changes in EE.next or MP wants to build upon some new features in it, then MP raises the required version of EE. Implementations that don't provide a new version of EE wouldn't claim compatibility with the whole MP but only with a list of MP specs that provide, even if it was all the core MP specs. Once they provide also the new version of EE Core Profile, they would again claim full MP compatibility

I see no need for MP lite. It wouldn't be a separate profile like Jakarta EE Web Profile because it would still rely on "some" implementation of the EE Core Profile specs. It would confuse users. On the other hand, stating the exact list of MP specs supported by a runtime that doesn't provide the whole MicroProfile would be more transparent. In fact Quarkus, for example, does it in exactly this way and it works for them. The value of MP Lite would be just in marketing, nothing else, and I don't think it's worth it to compromise the MicroProfile brand.

Ondro

po 30. 1. 2023 o 20:47 John Clingan <jcli...@redhat.com> napísal(a):

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/U5pffLWFOzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/78C0E617-3231-4CAE-AEE5-DDF2E933E86C%40redhat.com.

[Emily Jiang]

I am okay without MP Lite if there is a better choice.

For now, MP x release packages a fixed version of Jakarta EE y. If we allow y as the minimum version of Jakarta EE, do we:

1. How to specify the mininum version of Jakarta EE for microrpofile pom.xml, which packages all 8 MP core specs plus Jakarta EE dependent APIs (e,g. Jakarta EE 10 Core Profile) as maven dependency looks like the exact version

2. What is the required certification? Do we allow to certify MP x with all 8 MP core TCKs  + Jakarta EE y or above TCK?

Thanks

Emily

[Emily Jiang]

3. If MP release does not package Jakarta EE APIs, this will effecitively MP lite.

[Emily Jiang]

As promised, I have created this googledoc to capture and log some comments for this conversation. Please add your comments there.

Thanks

Emily

[Reza Rahman]

Added my updates and comments. Hope it helps.

I suggest we try to get broad ecosystem input on this before finalizing any decisions.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/23c45e22-0b96-42c8-80cb-044e26bfe2c5n%40googlegroups.com.

[Emily Jiang]

Thank you Reza! We will continue the discussion next week on all of the options listed in the doc. If anyone else has suggestions, please feel free to add them to the document.

Thanks

Emily

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/aff088e5-b148-4e34-4062-ae9b7e6ba696%40gmail.com.

--

Thanks
Emily

[Arjan Tijms]

Hi,

On Tuesday, January 31, 2023 at 6:09:14 PM UTC+1 Emily Jiang wrote:

As promised, I have created this googledoc to capture and log some comments for this conversation.

Thanks for creating the document Emily.

Could you also add my proposal of making the Micro Profile a profile of Jakarta EE to the document as proposal 4?

I know some of you may think it's a peculiar proposal, but I would like to ask those people to do the following thought experiment:

"If the micro profile didn't exist yet, and today, given the situation of how Jakarta EE is at Eclipse and everything, we would talk about adding a micro profile and associated new APIs. Would you then wanted to create a new working group for this new micro profile, or would you add it as a profile to Jakarta EE?"

My guess is you already know the answer to this, but truthfully for yourself, go through this mental exercise. It may also help to think about why we didn't create new or separate working groups for the core profile last year and for the web profile after it was transferred.

Kind regards,

Arjan Tijms

[Emily Jiang]

Thank you Arjan! Your proposal was added to the doc. We will continue the discussion of MicroProfile 7.0 next Tuesday.

[Emily Jiang]

After some lengthy discussion regarding the issue David raised in this thread that MicroProfile 7.0 is trying to solve, we revealed this googledoc  containing some proposals in yesterday's MicroProfile technical call. There are 4 proposals listed with cons/pros included.

For Proposal 4: Making the MicroProfile a profile of Jakarta EE, the group felt that there was a prerequisite to dissolve MicroProfile working group. This might not be feasible to release MicroProfile 7.0 in June 2023. With this in mind, the group felt it might be better for us to focus on Option 1, 2 and 3 and discuss further in the next few days till Tuesday next week. At the MicroProfile Live Hangout, we can decide whether we need further discussion or put up for a vote on Option 1, 2 or 3 among MicroProfile Working Members.

Proposal 1: MicroProfile releases support a minimum Jakarta EE versions

Proposal 2: Create MicroProfile Lite and rename the current umbrella to MicroProfile Full

Proposal 3: Release new MicroProfile versions when new Jakarta EE/Java SE versions are released

I understand not everyone was in yesterday's call. Please use this thread to share your thoughts.

Alternatively, please comment on the cons/pros of each individual proposal.

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 on the web visit https://groups.google.com/d/msgid/microprofile/76c6bc40-0d81-4dda-a62f-bd9591ed6a84n%40googlegroups.com.

--

Thanks
Emily

[Reza Rahman]

Added some very minor comments. I think it's thorough enough already for people to make a decision.

_______________________________________________
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

[Emily Jiang]

Thank you all for your contributions towards the google doc or the meeting conversation! At this week's live hangout, we discussed the proposals again. Since there were not many supporters for Proposal 2. It was suggested that only Proposal 1 and Proposal 3 would be put forward for a vote among working group members. If you have any other thoughts, please comment on the google doc or this thread. 

Thanks,

Emily

--

Thanks
Emily

[Reza Rahman]

+1. At this stage there is a high probability Microsoft will vote +0 on this particular issue. Both 1 and 3 have different tradeoffs, but are workable.

---

From: 'Emily Jiang' via MicroProfile <microp...@googlegroups.com>
Sent: Thursday, March 9, 2023 5:11 PM
To: MicroProfile <microp...@googlegroups.com>; Microprofile WG discussions <micropr...@eclipse.org>
Subject: [microprofile] Re: DISCUSSION Thread: MicroProfile dependency on Jakarta EE (tight or loose)

 

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAECq3A_ONxSOdJ4t-em1NHcRnEhvOST2_EzByOQNAp5__VEdOw%40mail.gmail.com.

[Arjan Tijms]

Hi,

I think anything that effectively enables option 4 is the best option. So option 3, where MP effectively (but perhaps not officially) joins the EE release train, should be the best option for now.

Kind regards,

Arjan Tijms

[Emily Jiang]

During the last 2 MP calls, we talked more about Proposal 1 and 3. Proposal 4 is not quite feasible in the short term as it involves more org updates. We can continue reassessing the situation in the future.

Proposal 3 requires a runtime to implement both EE updates and MP at the same time when the EE release happens, which might need some dedicated resources to spend on the implementation of both areas. Unless there is a runtime candidate to support this, it might not be a voting option because the plan cannot be executed without a backing runtime. Please shout here if you can support this.

With the above concerns, I suggest modifying Proposal 1 with the text in purple to be more proactive with embracing new EE releases with the hope of addressing some concerns.

Proposal 1:

The minimum Jakarta EE  version would be specified in the MicroProfile umbrella specification like it currently is in the component specifications.

• The minimum Jakarta EE Core Profile version would be 10 for MicroProfile 7

Implementations must pass the Jakarta EE TCK for the version and profile they implement.

Whenever a new EE release happens, MP needs to review whether the current release works with the new EE release. If not, a new MP release needs to be done as soon as possible

We can discuss this further at today's MP live hangout call.

Thanks

Emily

You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/U5pffLWFOzQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b8f5df43-4414-4d0e-8816-3a04b4e79ecbn%40googlegroups.com.

--

Thanks
Emily

[Emily Jiang]

A quick update on the progress of this topic:

On this week's MicroProfile Technical call, we finally tidied up the googledoc of MicroProfile dependency on Jakarta EE. Jan added and clarified Proposal 5. Please read if you have not. The consensus is to put Proposal 1, 3 and 5 for voting after the Live hangout on 16th May and leave this week for you to go through the proposals again. If you have any questions on any of the 3 proposals, please comment on this thread. Jan plans to send another email to advocate the newly added Proposal 5.

Thank you for your patience!

Thanks

Emily

--

Thanks
Emily